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Executive  Summary 


The  Information  Systems  Analysis  and  Design  class  (IMGT651)  was  invited 
to  undertake,  as  a  class  project,  an  investigation  of  problems  encountered  by 
people  within  AFIT  that  occur  when  responding  to  a  wide  variety  of  information 
requests.  The  investigation  of  these  problems  identified  a  number  of 
shortcomings  in  AFIT’s  management  of  information  that  underlie  and  cause 
these  problems.  These  shortcomings  include: 

1 .  Lack  of  knowledge  about  where  information  is  stored. 

2.  Lack  of  knowledge  about  using  the  information  systems  that  are  available. 

3.  Difficulty  using  some  of  the  information  systems  that  are  available. 

4.  Lack  of  a  comprehensive  plan  for  information  management  within  AFIT. 

5.  Lack  of  a  clear  authority  for  information  management  policy. 

6.  Lack  of  an  Executive  Information  System  to  support  information  requests. 

Based  on  these  shortcomings,  a  number  of  recommendations  were 
developed  to  address  and  improve  the  management  and  use  of  information 
within  AFIT.  The  recommendations  are  grouped  according  to  the  anticipated 
horizon  for  implementation:  near-term,  intermediate-term,  and  long-term. 
Although  it  might  seem  that  attacking  the  last  recommendation  (creating  an 
executive  information  system)  first  would  solve  the  bulk  of  the  problems,  it  can 
not  be  adequately  addressed  until  the  preceding  problems  are  rectified.  The 
specific  recommendations  are  as  follows: 

Near-Term 

1 .  Identify  and  assign  responsibility  for  data  administration  and  database 
administration. 

2.  Document  and  provide  information  on  where  information  is  stored. 

3.  Provide  training  and  documentation  on  use  of  existing  systems. 

4.  Complete  and  Implement  policies  on  database  management  and 
configuration  control. 

5.  Design  and  implement  a  user-friendly  “front-end”  application  for  some 
existing  databases. 

Intermediate-Term 

1 .  Integrate  and  coordinate  existing  databases. 

Long-Term 

1 .  Migrate  “stand-alone”  information  files  into  the  overall  framework  of  an  AFIT 
strategic  information  management  plan. 

2.  Develop  an  Executive  Information  System  (EIS)  and  long-term  view  of  AFIT’s 
information  needs. 
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Introduction 


This  systems  analysis  project  was  undertaken  in  response  to  a  request  from 
AFIT/XO  to  examine  AFIT’s  information  systems.  The  members  of  the  project 
team  are  members  of  the  AFIT/LA  course  IMGT  651,  and  are  under  the  direction 
of  the  class  instructor,  Dr.  Alan  Heminger,  Associate  Professor  of  Information 
Resources  Management.  The  team  was  led  by  Capt  Shari  Miles.  All  of  the  team 
members  are  students  in  the  AFIT/l_A  GIR  (Information  Resource  Management) 
program: 


1st  Lt  Heather  Adams 
Capt  David  Gaines 
Capt  Gordon  Geison 
1st  Lt  Jeffrey  (J.T.)  Hennes 
Capt  Fredrick  (Bill)  Knaak 
Capt  Shari  Miles 


Fit  Lt  Trevor  Plant 
Capt  Pamela  Quintero 
Capt  Steve  Robertson 
Capt  Lori  Rogers 
Capt  Greg  Schechtman 
1st  Lt  David  Snoddy 


Project  Introduction 

In  December  1995,  Lt  Col  Wayne  Stone  (AFIT/XO)  approached  Dr.  Alan 
Heminger  (AFIT/LAR)  with  a  project  proposal  for  his  IMGT  651  class.  The 
proposed  project  entailed  performing  an  investigation  of  problems  encountered 
when  responding  to  various  information  requests  on  behalf  of  the  Commandant. 
Often  the  information  is  difficult  to  locate,  particularly  in  the  desired  format,  and 
much  time  is  spent  looking  for  it.  Further,  similar  requests  often  result  in 
inconsistent  responses,  leading  to  confusion  and  additional  time  spent  trying  to 
reconcile  the  different  responses.  Frequently,  the  difference  in  responses 
cannot  be  adequately  reconciled. 


Objective  and  Scope 

The  objective  of  this  project  was  to  provide  recommendations  to  the  AFIT 
Commandant  regarding  AFIT’s  information  systems  and  information 
management  practices  to  help  the  Commandant  respond  quickly  and  accurately 
to  internal  management  and  external  advocacy  information  requests.  The  scope 
of  this  project  was  constrained  in  three  ways:  (1)  Limit  analysis  to  processes 
that  satisfy  the  Commandant’s  information  requests  (ad  hoc  or  periodic),  (2) 
Consider  only  AFIT  directorates  and  schools  as  information  sources,  and  (3) 
Exclude  day-to-day  operations  of  AFIT  directorates  and  schools  unless  they 
have  a  direct  bearing  on  the  Commandant’s  information  needs.  The  systems 
analysis  and  design  team  also  noted  that  any  recommendations  would  need  to 
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be  compatible  with  Air  University  (AU)  and  Air  Education  and  Training  Command 
(AETC)  information  and  system  architectures. 

In  determining  the  scope  of  the  project,  the  team  realized  it  must  first  gain  an 
understanding  of  AFIT’s  current  information  requirements.  Doing  so  required 
answering  questions  such  as  the  following:  “What  kind  of  information  is  currently 
requested,  either  by  internal  or  external  sources?  What  information  is  currently 
stored  and  maintained?  Where  is  this  information  stored  and  maintained?  How 
is  it  stored  and  maintained?  By  whom?”  After  receiving  preliminary  answers  to 
these  questions,  the  team  scoped  its  project  to  address  those  systems  and 
practices  found  within  AFIT. 


Figure  1  AFIT  Information  System  Context  Diagram  for  Responding  to  Information  Requests 


Figure  1  depicts  the  relationship  between  AFITs  information  systems  and 
various  internal  and  external  entities  as  they  relate  to  satisfying  information 
inquiries  on  behalf  of  the  Commandant.  At  different  times,  the  Commandant 
may  request  information,  provide  feedback  on  reports  generated,  or  be  the 
recipient  of  reports  generated  by  the  staff.  The  analysis  team  focused  its  efforts 
on  those  systems  and  practices  falling  within  the  “Satisfying  Requests  for 
Information”  box  shown  in  Figure  1 .  Therefore,  systems  existing  at  AU  or  at 
AETC  are  defined  as  being  outside  the  bounds  of  this  analysis  project. 

Without  a  good  understanding  of  the  systems  and  resources  already 
available  within  AFIT,  the  team  could  not  make  an  informed  recommendation  to 
the  Commandant  --  it  was  imperative  that  the  team  first  understand  the 
information  architecture  within  AFIT.  The  team,  thus,  began  by  exploring  the 
underlying  information  architecture  within  AFIT. 
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Approach 

This  project  broadly  encompassed  all  of  AFIT,  therefore,  the  team 
recognized  that  it  must  contact  members  of  AFIT  who  were  involved  with  the 
information  needs  of  the  Commandant.  Theoretically,  this  could  include  every 
member  of  the  faculty  and  staff  at  AFIT.  The  team  recognized  the  importance  of 
gaining  the  required  information,  but  given  the  time  constraints  involved,  the 
most  practical  approach  was  to  rely  on  knowledgeable  points  of  contact  (POCs) 
provided  by  Lt  Col  Stone.  These  POCs  represented  each  school  and  directorate 
within  AFIT.  Others  would  later  be  contacted  as  the  project  progressed  and  the 
need  arose. 

The  team  considered  several  possible  techniques  for  gathering  information 
from  the  POCs  and  decided  that  the  most  appropriate  was  likely  to  be  personal 
interviews.  Other  techniques  considered  included  surveys  and  questionnaires, 
group  brainstorming  sessions  and  use  of  a  Group  Decision  Support  System 
(electronic  group  tool).  This  last  technique  was  employed  for  one  interview 
session,  and  for  several  of  the  project  team  working  sessions,  and  proved  to  be 
an  effective  tool.  Surveys  and  questionnaires  were  considered  to  be 
inappropriate  during  this  initial  stage  of  the  project. 

Having  decided  on  interviews  as  the  primary  means  of  data  collection,  the 
team  prepared  a  series  of  questions  designed  to  draw  the  appropriate 
information  from  each  interviewee,  and  developed  a  standard  procedure  for 
conducting  the  interviews  and  debriefs.  The  project  team  was  then  divided  into 
teams  of  two  and  each  team  was  assigned  a  list  of  interviewees  from  the  list  of 
POCs  provided  by  Lt  Col  Stone. 
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Investigation 

The  first  formal  interview  was  conducted  with  Lt  Col  Stone  with  the  dual  aims 
of  testing  the  interview  instrument  and  procedure  and  obtaining  an  overview  of 
the  organizational  environment  from  the  point  of  view  of  XO.  This  initial  interview 
was  successful  in  achieving  both  aims  and  signaled  the  go  ahead  for  the  other 
interviews. 

In  brief,  the  interviews  were  designed  to  encourage  the  interviewees  to 
discuss  their  involvement  with  the  information  process  in  general  terms.  This 
open-ended  question  was  used  to  initiate  the  interview  and  to  encourage  the 
interviewee  to  speak  freely.  The  interview  then  progressed  to  more  specific 
questions  to  focus  on  information  of  interest  to  the  team.  Examples  of  follow-up 
questions  included  targeting  types  of  information  provided  to  the  command 
section,  learning  where  the  information  was  stored,  how  it  was  gathered,  and 
how  it  was  finally  presented.  By  gathering  this  information  in  face-to-face 
interviews,  the  team  was  able  to  gain  an  understanding  of  AFIT’s  information 
processes  and  obtain  copies  of  information  products  being  prepared  on  a  regular 
and  ad  hoc  basis.  The  team  was  also  able  to  identify  some  of  the  manual 
information  stores  and  databases  contained  within  AFIT. 

Upon  completion  of  each  interview,  an  interview  report  was  prepared  and 
returned  to  the  interviewee  for  coordination  and  approval.  The  finalized  interview 
report  was  forwarded  to  the  rest  of  the  project  team  members  and  copies  of  any 
information  products  were  provided  to  the  analysis  team  members. 
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Findings 

Upon  completion  of  the  interviews,  the  analysis  team  compiled  and 
reconciled  the  assorted  information,  data  flows,  and  process  diagrams.  The 
team  was  specifically  interested  in  identifying  existing  information  processes  and 
data  stores  used  in  satisfying  those  processes.  The  team  used  this  information 
to  construct  a  view  of  AFIT’s  current  information  systems  and  then  compiled  lists 
of  internally  supported  and  externally  mandated  data  systems.  These  systems 
represented  both  manual  and  automated  information  systems.  We  then 
performed  a  detailed  analysis  of  this  information  to  draw  conclusions  regarding 
the  diverse  information  challenges  presented  by  AFIT’s  current  information 
systems  and  information  management  practices. 

It  should  be  noted  that  the  concerns  raised  while  examining  AFIT’s 
information  systems  and  information  management  practices  are  fairly  typical  of 
those  found  in  many  large,  contemporary  organizations.  The  tremendous  strides 
in  information  technology  have  resulted  in  an  information  explosion,  which  affect 
almost  all  organizations  of  any  size  and  complexity. 


View  of  Current  Architecture  (AS-IS) 

The  investigative  process  identified  many  information  systems  within  AFIT; 
some  manual,  some  automated,  and  many  semi-automated.  The  size  and 
complexity  of  AFIT’s  operations  has  led  to  the  development  of  many  unrelated 
and  independent  views  of  data  vital  to  AFIT’s  operations.  During  the  team’s 
exploration  it  has  focused  on  those  systems  that  are  used  as  information  sources 
for  the  Commandant. 

In  reviewing  these  systems  and  determining  how  best  to  present  the  data, 
we  found  the  most  appropriate  way  to  represent  the  organization  of  these 
interrelated  systems  was  to  provide  a  graphical  representation  in  two  parts: 
systems  internal  to  AFIT  and  systems  mandated  by  external  organizations.  This 
representation  has  been  arranged  in  a  topological  map  in  Figures  2  and  4,  with 
the  intent  of  giving  an  overview  of  the  computing  environment  at  AFIT.  Further 
explanation  is  provided  in  Table  1  which  contains  a  matrix  view  of  the  systems 
identified  and  the  offices  that  use  those  systems.  It  provides  a  baseline  for 
identifying  those  systems  that  are  under-utilized  or  that  have  been  generated  by 
and  for  individual  offices.  The  individual  systems  are  described  in  more  detail  in 
Appendix  1 ,  The  AS-IS  Architecture. 
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Table  1  Application  to  Office  Cross  Reference  Matrix 


Internally  Supported  Data  Systems 

Figure  2  contains  a  map  of  those  systems  created  and  maintained  in-house 
by  AFIT  (or  AFIT-sponsored  contractors).  The  primary  goal  of  this  map  is  to 
identify  systems  and  their  users,  not  necessarily  proyide  detailed  information  on 
what  is  stored  in  them.  The  picture  that  the  team’s  investigation  formed  highlights 
the  need  for  a  review  of  the  information  systems  that  are  internal  to  AFIT. 
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Information  Systems  Supported  By  AFIT 
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Figure  2  AFIT  Supported  Information  Systems 


In  general  terms,  the  four  largest  of  the  internal  information  systems  are 
stored  in  an  Oracle  relational  database  system  (Figure  3).  Other  systems  store 
their  information  through  other  relational  database  management  systems,  such 
as  dBase  5  or  Paradox.  Still  others  store  their  information  in  non-database 
environments,  such  as  in  Word  or  Excel  files.  This  is  significant  because 
information  that  is  stored  in  a  relational  database  management  system  can  be 
stored  physically  once,  then  accessed  and  shared  by  many  applications,  each 
with  its  own  view.  The  result  of  this  is  intended  to  be  a  common  pool  of  carefully 
managed  data,  with  little  duplication,  and  easily  created  and  maintained 
applications  to  access  it.  With  the  four  largest  systems  accessing  a  single 
relational  database  management  system,  it  should  provide  the  setting  for  a 
common  pool  of  carefully  managed  data.  Unfortunately,  that  did  not  turn  out  to 
be  entirely  the  case.  Further  digging  into  the  structure  of  the  data  in  the  Oracle 
database  uncovered  that  there  is  not  a  single  pool  of  non-redundant  data. 
Apparently,  in  many  cases,  as  new  applications  were  added  each  created  its 
own  files  of  data.  This  resulted  in  the  same  data  being  stored  in  more  than  one 
place,  perhaps  called  by  different  data  names,  and  with  different  data  attributes. 
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Figures  ViewofAFITSIS 

Multiple  pools  of  redundant  data  are  likely  to  lead  to  updates  and  data 
entries  not  being  made  to  all  of  the  relevant  data.  As  a  simple  example,  consider 
a  person’s  address  stored  in  two  different  data  tables.  If  there  is  a  change  of 
address,  and  it  is  only  changed  in  one  table,  then  one  can  get  two  different 
addresses  for  this  person,  depending  on  which  table  one  consults.  Even  worse, 
it  may  not  be  possible  to  tell  which  one  is  correct,  requiring  more  work  to 
reconcile  the  discrepancy. 

There  are  several  small  local-use  systems,  with  little  or  no  database 
administration  support.  These  systems  are  often  populated  with  data  from 
information  stored  in  applications  such  as  AFITSIS  and  AFIT’s  Civilian  Education 
System  (ACES).  However,  since  they  may  not  have  reconciliation  procedures  to 
ensure  consistency  with  the  larger  databases,  it  is  likely  that  they  will  become 
inconsistent  over  time.  This  may  help  to  explain  the  difficulty  in  reconciling 
disparities  between  data  collected  through  multiple  sources.  A  prime  example  of 
the  potential  for  redundancy  is  the  existence  of  a  registrar  style  database  within 
LS  used  for  tracking  student  information.  This  competes  directly  with  the 
systems  used  by  RR. 
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AFITSIS  is  a  conglomeration  of  four  primary  applications  and  utilizes 
upwards  of  250  Oracle  relational  tables  (Figure  3).  The  team  discovered  that  the 
component  tables  of  most  of  the  applications  contain  redundant  fields  which  can 
result  in  inconsistent  data  stores.  Because  the  same  item  may  be  called 
different  things  in  the  different  applications,  it  is  not  possible  to  be  sure  that  all 
redundancies  are  found  through  casual  observation.  A  detailed  analysis  of  the 
various  tables  (beyond  the  scope  of  this  study)  will  be  necessary  to  be  sure  that 
all  redundancies  are  identified. 

STARS  is  the  largest  component  application  of  AFITSIS.  It  contains  almost 
200  tables  by  itself,  and  could  potentially  satisfy  most  of  the  Commandant’s 
information  needs,  if  combined  with  the  Civilian  Institution  Directorate’s  ACES. 

AFITSIS,  however,  suffers  from  a  malady  that  afflicts  many  of  the  earlier 
generation  of  RDBMS  implementations:  poor  documentation  and  little  training, 
along  with  what  the  users  perceive  to  be  a  user-surly  interface.  These 
perceptions  may  explain  to  some  extent  why  alternative  systems  (such  as  the 
registrar  replacement  in  LS)  have  blossomed  in  the  shadow  of  the  official 
system.  More  than  one  office  indicated  they  could  not  rely  on  information  being 
supplied  by  AFITSIS  (STARS),  because  they  themselves  were  not  entering 
updated  information,  again  because  of  the  interface. 

It  is  the  systems  analysis  and  design  team’s  understanding  that  the  user 
interface  issue  is  being  addressed  in  some  form  with  the  migration  to  Oracle  v7 
RDBMS  which  utilizes  a  graphical  user  interface  (GUI)  and  easier  to  use  query 
language.  This  migration  will  provide  an  opportunity  to  perform  a  reengineering 
of  the  AFIT  information  environment. 


Externally  Mandated  Data  Systems 

In  addition  to  internally  developed  and  managed  information,  AFIT  also 
interacts  with  outside  agencies,  such  as  AU  and  AETC.  These  agencies  have 
their  own  data  needs  that  often  require  compliance  from  AFIT.  Thus,  in  addition 
to  developing  internal  standards,  AFIT  must  support  the  information  system 
needs  of  those  outside  agencies  to  which  it  reports.  Prime  examples  of  these 
systems  are  PC-Ill  and  DFAS.  These  are  mainframe  based  systems  and  use 
network  connections  to  allow  updates  of  the  information  to  the  host  DBMS. 
There  are  some  PC-based  systems  that  are  mandated  for  standardization  of 
data  and  management  techniques  within  the  Air  Force,  not  just  AFIT.  Examples 
of  these  systems  are  the  ACQMAN  and  OCQMAN,  which  are  Enable 
applications  used  for  library  financial  management. 


9 


Air  Force  Institute  of  Technology 


IMGT651 


Manual  Systems 

In  addition  to  the  computerized  systems  used  in  AFIT  there  are  many 
manual  or  semi-automated  processes  in  each  of  the  offices  interviewed.  We 
found  in  some  instances  that  the  reason  for  several  manual  systems  is  a  lack  of 
trust  in,  and  reliability  of,  information  maintained  in  the  primary  electronic 
information  sources.  It  was  also  learned  that  many  people  do  not  know  what 
information  is  available  in  the  various  electronic  information  systems.  These 
manual  systems  consist  of  paper  records  and  electronic  files  on  PCs  in 
(generally)  one  of  the  MS  Office  formats:  Word,  Excel  or  Access.  These 
systems  are  typically  the  systems  used  to  prepare  information  for  presentation  to 
the  Commandant  or  in  response  to  queries. 


Sources  of  Information  Requirements 

During  an  interview,  the  Commandant  expressed  a  need  to  access  AFlT’s 
aggregate  cost  and  throughput  data.  The  form  of  this  information  falls  within 
three  broad  categories.  First,  information  is  needed  on  student  scholastic 
characteristics.  This  includes  such  things  as  GRE  scores,  attendance  and 
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graduation  rates,  and  the  number  of  student  waivers.  The  Commandant  also 
wants  non-scholastic  information,  e.g.  student  numbers  or  demographics, 
research  sponsorship,  and  the  details  of  follow-on  assignments.  Finally, 
anything  that  impacts  the  budget  process  needs  to  be  readily  accessible. 

The  Commandant’s  questions  are  often  routed  to  the  schools  and 
directorates  to  answer  due  in  part  to  the  executive  officer’s  lack  of  an  accessible 
database.  This  has  led  to  directorates  experiencing  difficulty  separating 
information  needed  to  support  the  Command  Section  from  that  used  in  day-to- 
day  operations.  Many  of  the  directorates  feel  they  contribute  very  little  on  a 
continuing  basis  to  the  Commandant's  information  needs.  However,  there  was  a 
feeling  that  many  ad  hoc  reports  indirectly  benefit  the  Commandant.  For 
instance.  Cl  stated,  “We  do  quite  a  few  ad  hoc  reports  for  CC  through  XO  ... 
Many  of  the  ad  hoc  questions  are  very  short  notice  requests  for  information  that 
simply  is  not  available.” 

Ad  hoc  queries  have  had  a  significant  impact  on  AFIT’s  information  needs. 
The  directorates  are  forced  to  respond  to  inquiries  from  Air  Staff,  AD,  and 
various  MAJCOMs.  Many  of  these  have  short  suspenses  and  are  negatively 
affected  by  the  lack  of  a  coordinated  database.  CE  provides  an  example  of  this. 
They  have  no  automated  rosters  or  transcripts.  All  queries  are  done  by  manually 
checking  papers  in  a  file  cabinet.  SC  (in  providing  information  for  the  financial 
plan)  and  XOX  (for  information  not  in  STARS)  relayed  similar  examples.  The 
Commandant  acknowledges  this  is  a  problem:  some  questions  are  not  asked 
simply  because  it  would  require  too  much  manpower  to  provide  answers.  This  is 
symptomatic  of  problems  with  the  existing  systems. 


Difficulty  Using  Existing  Systems 

AFIT  personnel  have  difficulty  using  the  existing  information  systems  to 
maintain,  manipulate,  and  retrieve  essential  data.  The  lack  of  a  unified, 
coordinated  data  model  and  the  lack  of  education  and  training  to  use  the 
systems  are  two  major  impediments. 

Our  research  has  indicated  that  many  AFIT  personnel  have  difficulty  in 
finding  needed  information  in  the  existing  information  systems.  This  difficulty  in 
locating  needed  information  has  led  people  to  create  individual  data  stores  in 
order  to  meet  day-to-day  information  needs.  Some  of  these  data  stores  include 
manual  filing  systems,  others  include  extracting  information  out  of  an  existing 
system  (such  as  STARS)  and  entering  the  data  into  a  spreadsheet  (such  as 
EXCEL)  in  order  to  manipulate  the  data  and  generate  the  necessary  reports. 
These  individual  practices  have  caused  data  duplication,  data  inconsistencies, 
and  a  lack  of  confidence  in  the  reliability  of  the  information.  Furthermore,  many 
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offices  routinely  spend  an  inordinate  amount  of  time  searching  for  information 
because  they  do  not  know  it  is  readily  available  in  an  existing  AFIT  system. 

Lack  of  education  and  training  is  another  reason  AFIT  personnel  have 
difficulties  using  existing  information  systems.  Many  individuals  have  not  been 
trained  on  how  to  use  the  current  systems  to  meet  their  information  needs. 
Further,  most  people  do  not  know  what  types  of  data  the  databases  contain  or 
how  to  access  that  data.  Moreover,  instruction  manuals  seem  to  be  in  short 
supply.  Of  the  few  individuals  who  could  access  the  data,  virtually  all  claim  that 
the  user-interface  is  difficult  to  use.  In  general,  most  individuals  have  not  had 
training  on  the  systems  and  do  not  know  who  to  consult  for  support.  This  is 
especially  troublesome  since  AFIT  personnel  must  respond  quickly  to  numerous 
requests  for  information  on  a  daily  basis. 


Procedural  Issues 

In  addition  to  problems  using  the  existing  systems,  many  problems  arise 
from  the  existing  procedures  for  getting  information.  Many  ad  hoc  requests  are 
received  and  because  they  are  ad  hoc,  there  is  no  particular  tracking  system  for 
this  type  of  information  as  there  would  be  for  periodic  reports.  In  addition,  some 
of  these  ad  hoc  requests  are  repeated  so  it  would  be  helpful  to  keep  a  file  or 
database  of  some  sort  that  could  be  searched  if  similar  information  is  requested 
again.  One  office  did  keep  a  notebook  of  previous  answers  to  ad  hoc  requests. 
A  potential  problem  with  adopting  this  approach,  however,  is  that  it  may  be  hard 
to  keep  the  log  updated. 

There  are  also  problems  with  poor  wording  of  requests  or  conflicting 
definitions  of  words  within  the  requests.  Many  offices  are  not  sure  what 
information  is  being  asked  for  because  there  could  be  many  ways  of  interpreting 
the  request.  A  simple  example  is  a  request  for  the  number  of  students  at  AFIT. 
To  some  offices  this  would  include  international  students  whereas  to  others  it 
would  not.  Some  say  the  number  of  students  is  the  quota  eventually  reached 
but  some  say  it  is  the  number  of  students  in  the  actual  seats  at  AFIT.  Also,  if 
requests  are  filtered  down  to  many  different  offices,  the  details  of  the  request 
may  eventually  be  filtered  out  and  the  person  who  is  filling  the  request  ends  up 
providing  insufficient  or  unnecessary  information.  Filtering  requests  down  to 
other  offices  can  also  result  in  diminishing  priority.  A  person  that  is  asked  to  get 
information  regarding  the  request  may  not  see  it  as  top  priority  while  the  person 
waiting  to  answer  the  request  may  feel  it  is  of  very  high  priority,  depending  on 
where  the  request  is  coming  from  and  how  soon  it  is  to  be  answered. 

Another  area  of  concern  is  the  keeping  of  records  regarding  student 
research  and  transitions.  Records  need  to  be  kept  on  student  throughput  and 
on-time  graduates  for  the  civilian  and  military  schools.  For  example,  no  records 
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are  kept  in  reference  to  who  the  receiving  commands  of  the  students  are  and 
what  theses  or  dissertations  were  completed  by  which  students.  The  questions 
are:  What  kind  of  information  needs  to  be  tracked  and  who  should  track  that 
information?  Value  added  needs  to  be  considered  when  tracking  certain 
information.  For  example,  the  following  questions  should  be  asked  when 
deciding  whether  or  not  to  maintain  a  particular  piece  of  information;  “Does 
tracking  this  information  add  value  to  my  job  or  tasks?  Is  it  worthwhile  to  have 
this  information  and  to  have  this  information  updated?” 
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Discussion 


Finding  Information 

During  the  team’s  examination  of  AFIT’s  information  management,  the 
individuals  we  spoke  with  from  across  AFIT  regularly  emphasized  three  crucial 
problems  with  the  structure  of  data  at  AFIT.  First,  virtually  every  work  center 
recognized  that  there  was  no  single  definitive  source  of  information  that  covers 
the  whole  range  of  processes  supported  by  AFIT.  Information  is  maintained  in 
fragmented  and  isolated  packets  that  often  serve  the  particular  narrow  needs  of 
an  individual  work  center,  but  cannot  be  made  easily  available  to  those  outside 
that  center.  The  problem  arising  from  this  situation  is  that  information  crucial  to 
senior  leadership  is  often  hidden  behind  a  confusing  array  of  disparate  storage 
methods. 

A  lot  of  the  information  identified  as  needed  was  discovered  to  exist  in  some 
database  or  other  form  but  the  requester  does  not  know  whom  to  ask  or  what 
office  is  responsible  for  maintaining  the  data.  Many  times  individuals  do  not 
believe  the  information  needed  or  requested  is  currently  being  captured,  when  in 
fact  the  information  is  available  but  in  a  form  or  location  unknown  to  those  with  a 
genuine  need  to  know.  An  example  of  the  need  for  this  education  can  be 
recognized  by  the  following  scenario.  Once  a  year,  surveys  are  received  from 
the  Council  of  Graduate  Schools,  National  Science  Foundation,  and  Integrated 
Post  Secondary  Data  System.  In  an  effort  to  gather  the  data  for  these  surveys,  a 
request  was  sent  to  RR  to  supply  data  on  the  number  of  students  by  gender  and 
ethnic  background.  RR  does  not  track  gender  and  ethnic  background  so  a 
manual  search  through  all  student  records  was  performed  to  gather  the  data. 

This  information  could  have  been  gathered  through  PC-Ill.  The  personnel 
systems  manager  (PSM),  could  have  easily  written  a  query  to  pull  this 
information  from  the  Personnel  Data  System  (PDS).  An  overall  systems  model 
detailing  data  sources  and  responsibility  would  be  beneficial. 

Consistency  of  Information 

Multiple  sources  of  information  (often  covering  overlapping  categories)  mean 
that  there  will  inevitably  be  inconsistencies  in  the  data  that  is  retrieved  from  these 
non-integrated  and  non-coordinated  databases.  Information  is  updated  at 
different  times,  in  different  ways,  and  for  different  purposes.  When  a  record  is 
updated  in  one  database,  similar  information  contained  in  a  separate  database  is 
immediately  rendered  inconsistent.  Unless  there  is  automatic,  seamless 
communication  between  the  various  data  sources,  inconsistencies  are 
unavoidable.  Each  data  source  also  has  elements  of  information  defined  in 
unique  ways  that  may  not  correspond  to  the  data  definition  contained  in  other 
information  sources.  For  example,  a  question  that  seems  as  clear  as  How 
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many  students  are  assigned  to  AFIT?”  might  get  a  range  of  answers  from  400  to 
4,000  depending  on  exactly  what  one  means  by  assigned  to  AFIT.  The  problem 
is  compounded  by  asking  for  more  specific  information  which  requires  further 
interpretation,  such  as  specifying  a  year.  For  example,  does  the  requester  mean 
fiscal  year,  calendar  year,  or  academic  year?  Asking  three  different  offices  the 
“same”  question  can  lead  to  three  different  answers  because  the  question  may 
not,  in  fact,  mean  precisely  the  same  thing  to  each  of  those  offices.  Subtle 
distinctions  in  meaning  (often  not  appreciated  by  those  requesting  the 
information)  can  lead  to  significant  discrepancies  between  what  the  requester 
intended  and  what  the  action  office  understood.  Standard  definitions  of  crucial 
data  elements  would  help  alleviate  miscommunication  and  clarify  information 
requests. 


Accountability  for  Information 

The  splintering  of  information  into  widely  scattered  databases  leads  to  a 
diffusion  of  accountability.  Work  centers  too  often  focus  on  their  individual 
concerns  without  a  holistic  appreciation  for  how  their  information  fits  into  the 
overall  data  structure.  This  leads  to  the  perception  that  AFIT’s  corporate 
information  resources  do  not  belong  to  anyone  in  particular.  Therefore,  no  one 
is  identified  as  the  responsible  party  for  ensuring  the  uniformity,  currency,  and 
accuracy  of  the  vast  array  of  information  that  is  captured  daily  throughout  the 
Institute.  This  dilution  of  accountability  undermines  the  critical  sense  of 
ownership  that  inspires  vigilant  attention  to  detail  and  accurate,  timely  updates  of 
information.  In  conjunction  with  consolidating  and  integrating  databases,  clear 
lines  of  responsibility  also  need  to  be  established  that  define  who  owns  the 
information. 


Integration  of  Information  Systems 

The  AFIT  managerial  staff  recognized  the  need  to  improve  the  management 
of  information  within  AFIT.  The  current  systems  are  diverse  and  poorly 
integrated.  Efforts  to  better  integrate  the  systems  have  been  incomplete  and 
therefore,  often  unsuccessful.  The  result  is  that  AFIT  has  a  variety  of  disparate 
information  systems,  some  of  which  do  not  “talk”  to  each  other,  and  others  of 
which  are  hard  to  use.  Furthermore,  the  information  contained  in  AFIT’s 
information  systems  is  often  redundant,  inconsistent,  or  simply  hard  to  find. 

For  example,  when  the  Commandant  receives  a  request  for  information, 
members  of  his  staff  respond  to  produce  a  report,  briefing,  or  other  suitable 
response  to  the  request.  Ideally,  the  information  would  be  pulled  from  one  or  a 
few  of  the  automated  databases,  along  with  some  information  from  manual 
systems.  Unfortunately,  that  is  not  what  usually  happens.  All  too  often,  the 
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information  can  not  be  found  in  an  automated  system,  and  much  time  is  spent 
searching  through  manual  sources.  Further,  it  is  often  not  clear  where  to  look  for 
information,  so  much  time  can  be  lost  simply  trying  to  identify  an  appropriate 
source.  To  further  compound  the  problem,  the  information  may  be  stored  in 
multiple  locations.  When  this  happens,  updates  often  are  done  on  only  one 
source,  leading  to  “update  anomalies”.  The  information  is  inconsistent,  which 
can  lead  to  inconsistent  results,  depending  on  which  source  is  used.  There  is 
currently  no  simple  way  to  produce  needed  information  quickly  and  accurately. 
Additionally,  because  there  is  no  standardized  procedure  to  collect  and 
disseminate  information,  follow-on  reports  may  also  produce  inconsistent  results. 


Information  Management 

Information  management  entails  two  key  responsibilities,  both  of  which  must 
be  addressed  to  ensure  proper  use  of  AFIT’s  information  resources.  The  first  of 
these  is  data  administration.  Data  administration  involves  the  responsibility  for 
development  and  implementation  of  the  overall  plan  for  collecting,  storing,  and 
using  AFIT’s  information.  It  is  predicated  on  the  understanding  that  information 
is  a  crucial  organizational  resource,  and  as  such,  plans  for  its  use  must  be 
developed  in  a  context  of  overall  organizational  needs.  For  instance,  data 
administration  involves  decisions  about  what  information  to  collect  and  store,  as 
well  as  who  should  be  able  to  read,  write,  and  modify  it.  In  a  modern  information 
system,  in  which  information  is  stored  physically  once,  and  used  by  many  sub¬ 
units  of  the  organization,  these  decisions  become  very  important.  They  should 
be  made  with  managerial  needs  in  mind,  and  should  be  based  on  the  AFIT 
information  management  plan.  Only  through  this  top-down  view  of  information 
management  can  problems  such  as  data  duplication  and  data  inconsistency  be 
controlled,  and  access  to  needed  information  in  a  timely  manner  be  ensured. 

The  second  key  responsibility  is  database  administration.  Although  this 
sounds  at  first  like  data  administration,  database  administration  is  a  more 
technical  responsibility  involving  the  proper  management  of  AFITs  various 
computerized  database  management  systems.  Physical  design  of  the  actual 
data  files  is  managed  at  this  level,  as  well  as  implementation  of  information 
management  policy,  such  as  the  actual  assignment  of  rights  to  read,  write,  and 
modify  data  to  the  appropriate  people.  While  there  are  people  assigned 
responsibilities  for  database  administration  within  AFIT,  there  appears  to  be 
room  for  improvement  in  the  focus  and  comprehensiveness  of  the  assigned 
responsibilities. 

The  team  learned  that  policy  directives  were  being  drafted  in  1994  by  Barb 
Cerny  to  manage  AFIT’s  information  systems.  Ms  Cerny,  however,  no  longer 
works  at  AFIT  and  no  one  has  taken  over  the  completion  of  these  responsibilities 
since  she  departed.  These  directives  should  be  finished  and  implemented  as 
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operating  instructions  or  directives  to  guide  AFIT’s  information  resources  and 
existing  systems  in  the  correct  direction.  As  a  start,  there  should  be  at  least  two 
directives  written  for  AFIT.  The  first  should  be  a  policy  on  maintaining  AFIT’s 
databases  and  the  other  should  direct  the  establishment  of  a  configuration 
control  board.  The  implementation  of  these  policies  would  ensure  AFIT’s 
information  systems  have  a  specific  office  of  responsibility  and  would  also 
eliminate  problems  associated  with  the  maintenance  and  redundancy  of  data. 
Currently,  there  is  no  specific  person  or  office  to  make  clear  policy  regarding 
AFIT’s  information  needs.  The  responsibility  for  this  would  logically  belong  to  the 
assigned  data  administrator. 

The  data  administration  and  database  administration  responsibilities,  along 
with  the  database  management  and  configuration  control  policies,  are  typically 
components  of  an  Information  Management  Strategic  Plan.  This  plan  is  linked  to 
an  organization’s  strategic  plan  and  provides  a  scheme  for  managing  information 
used  in  business  operations,  and  identifies  the  roles  and  responsibilities  of  staff 
within  the  organization.  The  presence  of  this  plan  would  allow  AFIT  to  identify 
opportunities  for  integration  of  existing  data  stores  and  information  systems. 


Training  to  Use  AFITs  Information  Systems 

Training  on  use  of  existing  systems  and  documentation  for  the  use  of 
applications  would  be  beneficial  for  most  individuals  using  AFITSIS.  Analysis  of 
the  interviews  has  led  the  team  to  the  conclusion  that  (1)  the  majority  of  people 
within  AFIT  do  not  know  how  to  use  the  existing  systems,  and  (2)  without  a 
process  to  train  these  individuals,  AFIT  will  find  itself  in  this  same  position  into 
the  foreseeable  future.  It  was  mentioned  in  several  interviews  that  the  systems 
within  AFIT  are  difficult  to  access  and  the  team  has  since  discovered  that 
individuals  have  created  their  own  systems  to  store  and  maintain  the  data  they 
need.  This  is  due  in  part  to  the  individuals  not  knowing  how  to  use  the  systems 
they  have,  indicating  a  definite  lack  of  training.  The  training  program  should 
include:  (1)  catch-up  training  and  (2)  ongoing  training.  Initially,  training  should 
be  provided  to  bring  the  individuals  who  have  an  immediate  requirement  to 
access  data  up  to  speed  on  the  systems  that  currently  exist  within  AFIT.  This 
training  should  provide  instruction  for  using  query  languages  and  should  also 
provide  written  documentation  for  various  applications.  Ongoing  training  is 
needed  to  ensure  that  AFIT  staff  stay  proficient  in  using  the  systems  as 
upgrades  and  modifications  to  the  software  and  systems  occur  and  as  new 
employees  come  aboard. 
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Improved  User  Interfaces 

Historically,  creating  applications  would  be  a  mid-  to  long-term 
recommendation.  In  this  case,  however,  the  team  believes  it  may  be  possible  to 
quickly  create  new  user  interfaces  to  allow  simple  access  to  the  existing 
information.  The  team  recommends  identifying  key  areas  such  as  STARS, 
ACES,  and  ASAS  to  begin  with,  since  these  applications  are  the  most  widely 
used.  There  are  several  software  applications  that  exist  internally  to  AFIT  which 
could  be  used  for  this  purpose.  They  include:  Database  Reporting  with 
Impromptu,  Oracle  Reports,  and  Microsoft  Access.  AFIT  SC  personnel 
recommend  using  Microsoft  Access  because  of  its  capabilities  to  generate 
reports  and  perform  queries.  Moreover,  Microsoft  Access  works  in  a  windows 
environment  and  has  on-line  help  procedures  to  assist  users.  For  those 
individuals  who  will  be  working  with  Microsoft  Access  to  generate  reports  and 
perform  queries,  there  is  a  3-day  training  course  offered  through  the  Wright- 
Patterson  Campus,  which  is  free. 


Integration  of  Current  Databases 

The  storage  of  data  within  AFIT  is  fragmented  and  disjointed,  resulting  in 
rampant  data  redundancy  and  inconsistencies.  This  problem  can  be  addressed 
by  integrating  and  coordinating  the  databases.  The  first  step  toward  this 
integration  involves  thoroughly  mapping  the  tables  and  contents  of  all  the  current 
databases.  The  team  has  created  an  “AS-IS”  architectural  model  to  be  used  as 
a  baseline  for  improvements  (Appendix  1).  A  well-defined  architecture  would 
greatly  reduce  data  redundancy  and  its  resultant  accuracy  problems.  The 
Commandant  would  have  renewed  confidence  in  the  information  offered  in 
response  to  his  requests.  Some  of  the  keys  for  implementing  the  single 
database  architecture  include:  correctly  mapping  the  current  tables,  the 
changeover  process  used,  well-defined  data  definitions  for  the  integrated 
database,  and  a  well-maintained  map  of  the  structure.  It  is  also  important  to 
have  a  person  specificaily  assigned  to  the  integration  and  be  responsible  for  it  as 
an  on-going  activity.  The  responsibilities  for  this  would  belong  to  both  the  data 
administrator  and  the  database  administrator. 


Longer  Term  Improvements 

Migrate  “stand-alone”  information  files  into  the  overall  framework  of  AFIT’s 
information  management  strategic  plan.  The  result  of  migrating  stand  alone 
information  files  is  intended  to  create  a  common  pool  of  managed  data,  with  little 
duplication,  and  easier  access.  The  use  of  query  language  interfaces  to  this 
pool  of  information  will  enable  the  staff  to  quickly  generate  reports  or  temporary 
tables  on  which  to  base  documents  created  previously  by  a  word  processing  or 
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spreadsheet  application  (for  example,  Word  or  Excel).  Word  processing 
applications  are  typically  used  for  structuring  and  presenting  data  that  is 
retrieved  from  databases,  not  to  act  as  a  store  for  data  that  will  be  shared  and 
reused.  For  AFIT  to  migrate  these  “stand-alone”  files,  someone  will  need  to 
perform  a  detailed  analysis  and  reconciliation  of  data  contained  in  existing 
RDBMSs  and  data  stored  in  stand-alone  files.  An  additional  consideration  is  that 
of  data  which  is  not  currently  being  maintained  electronically  but  is  needed  to 
reply  to  requests  from  the  Commandant  or  other  agencies.  Once  the  stand¬ 
alone  files  are  integrated  there  will  be  improved  access  to  data  and  elimination  of 
redundant  sources  for  information. 

Develop  an  Executive  Information  System  (see  “TO-BE”  Model  in  Figure  5). 
Since  an  EIS  presupposes  that  the  information  to  be  accessed  currently  exists  in 
a  carefully  managed  system  or  systems,  it  is  important  that  AFIT’s  information 
systems  be  up-to-date  and  accurate.  This  does  not  mean  AFIT  would  have  to  do 
away  with  existing  information  systems.  Currently,  AFIT  has  several  applications 
which  access  several  databases  with  no  common  interface.  In  addition,  there 
are  several  “maverick”  systems  used  within  certain  work  centers  that  only  assist 
a  few  individuals.  This  has  caused  multiple  sources  for  information,  data 
inconsistency,  and  splintering  of  information  across  several  databases.  The 
team  recommends  adoption  of  the  “TO-BE”  model  with  multiple  applications 
using  common  interfaces  to  relational  databases  with  normalized  tables. 


19 


Air  Force  Institute  of  Technoiogy 


IMGT651 


Conclusion 

The  analysis  of  the  material  gathered  in  this  study  leads  to  a  number  of 

conclusions  about  the  use  of  information  and  information  systems  within  AFIT. 

1 .  There  is  frequently  a  lack  of  knowledge  about  where  information  is  stored 
within  AFIT’s  information  systems. 

2.  Many  people  do  not  understand  how  to  use  the  information  systems  that  are 
available.  There  appears  to  be  very  little  documentation  on  the  existing 
systems,  and  they  are  not  very  amenable  to  figuring  them  out  without  the 
documentation.  As  a  result,  people  find  work  arounds,  which  often  results  in 
creating  a  new,  off-line  information  system. 

3.  There  does  not  appear  to  be  a  Information  Management  Strategic  Plan  for 
AFIT.  This  plan  is  linked  to  an  organization’s  strategic  plan  and  provides  a 
scheme  for  managing  information  used  in  business  operations,  and  identifies 
the  roles  and  responsibilities  of  staff  within  the  organization.  The  presence  of 
this  plan  would  allow  AFIT  to  identify  opportunities  for  integration  of  existing 
data  stores  and  information  systems. 

4.  All  of  the  problems  listed  above  explain  why  there  is  not  an  executive 
information  system  (EIS)  at  AFIT  to  assist  managers  in  responding  to 
information  requests.  An  EIS  is  an  information  system  that  draws  its 
information  from  the  organization’s  other  information  systems.  In  their  current 
state,  they  cannot  dependably  support  an  EIS.  To  create  a  useful  EIS,  it  will 
first  be  necessary  to  address  the  problems  with  the  overall  management  of 
AFIT’s  information. 
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Recommendations 


The  AFIT  Commandant  recognizes  a  need  to  improve  information 
management  within  his  organization.  The  problems  AFIT  is  experiencing  occur 
in  many  organizations,  within  both  the  military  and  private  industry.  These 
problems  are  exacerbated  by  the  growing  complexity  of  modern  organization  and 
the  increasing  information  needed  to  manage  them.  At  the  same  time,  rapidly 
evolving  information  technology  increases  our  capability  to  mange  that 
information. 

AFIT  also  has  a  responsibility  to  develop  an  architecture  that  facilitates  open 
access  to  information  all  the  way  up  through  DoD.  Furthermore,  in  accordance 
with  DoD’s  Technical  Architecture  Framework  for  Information  Management 
(TAFIM),  all  information  systems  and  architectures  will  be  developed  in  a 
framework  that  allows  for  this  open  access  to  information  that  is  compatible 
throughout  DoD.  AFIT  should  not  only  look  down  within  its  organization  but  also 
up  to  those  organizations  to  which  they  report,  AU  and  AETC,  to  develop 
systems  consonant  with  theirs. 

With  the  foregoing  in  mind,  and  based  on  our  analysis,  we  have  developed  a 
set  of  recommendations.  They  will  be  addressed  as  near-,  intermediate-,  and 
long-term  recommendations.  We  feel  that  these  recommendations  will  result  in 
improved  productivity  and  quicker  data  retrieval,  along  with  greater  information 
accuracy  and  much  more  efficient  and  effective  information  systems  in  general. 
As  each  of  the  following  recommendations  is  implemented,  AFIT  will  move  one 
step  closer  to  a  more  integrated  and  coordinated  management  of  its  information. 
It  will  facilitate  a  better  way  to  respond  to  AFIT’s  information  needs.  The 
following  are  our  recommendations: 


Near-Term  Recommendations 

1.  Develop  an  Information  Management  Strategic  Plan. 

a.  Identify  and  assign  responsibilities  for  data  administration  and 
database  administration. 

Progress  towards  a  more  coherent  management  of  AFIT’s  information  is 
dependent  on  the  appointment  of  a  data  administrator  and  database 
administrator  to  fulfill  the  responsibilities  identified  in  the  “TO-BE” 
information  architecture  model  in  Figure  5. 

The  first  of  these  is  data  administration.  Data  administration  involves  the 
responsibility  for  development  and  implementation  of  the  overall  plan  for 
collecting,  storing,  and  using  AFIT’s  information. 

The  second  key  responsibility  is  database  administration.  Although  this 
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sounds  at  first  lik©  data  administration,  database  administration  is  a  more 
technical  responsibility  involving  the  proper  management  of  AFIT’s 
various  computerized  database  management  systems.  Physical  design  of 
the  actual  data  files  is  managed  at  this  level,  as  well  as  implementation  of 
information  management  policy. 


Figure  5  The  “TO-BE”  Model  for  AF IT’s  Information  Systems 


b.  Document  and  provide  information  on  where  information  is  stored. 

A  lot  of  the  information  identified  as  needed  was  discovered  to  exist  in 
some  database  or  other  form  but  the  requester  does  not  know  whom  to 
ask  or  what  office  is  responsible  for  maintaining  the  data.  As  part  of  this 
report,  the  team  has  provided  “AS-IS”  models  of  AFIT’s  data  flows  in 
Appendix  1  and  an  explanation  of  the  database  tables  in  Appendix  2. 

c.  Complete  and  implement  database  management  and  configuration 
control  policies. 

Two  directives  in  particular  need  to  be  written  for  AFIT.  The  first  should 
be  a  policy  on  maintaining  AFIT’s  databases  and  the  other  should  direct 
the  establishment  of  a  configuration  control  board.  The  implementation  of 
these  policies  would  ensure  AFIT’s  information  systems  have  a  specific 
office  of  responsibility  and  would  also  eliminate  problems  associated  with 
the  maintenance  and  redundancy  of  data. 
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2.  Provide  training  on  use  of  existing  information  systems. 

Training  on  use  of  existing  systems  and  documentation  for  the  use  of 
applications  would  be  beneficial  for  most  individuals  using  existing  AFIT 
systems.  The  training  program  should  include:  (1)  catch-up  training  and  (2) 
ongoing  training. 

3.  Design  and  implement  a  user-friendly  “front-end”  application  to  get 
information  from  existing  databases. 

Historically,  creating  applications  such  as  these  would  be  a  mid-  to  long-term 
recommendation.  In  this  case,  however,  the  team  believes  the  customization 
and  use  of  particular  applications  within  AFIT  would  be  productive  in  the 
near-term. 


Intermediate-Term  Recommendations 

4.  Integrate  and  Coordinate  Existing  Databases. 

The  storage  of  data  within  AFIT  is  fragmented  and  disjointed,  resulting  in 
rampant  data  redundancy  and  inconsistencies.  This  problem  can  be 
addressed  by  integrating  and  coordinating  the  databases.  The  first  step 
toward  this  integration  involves  thoroughly  mapping  the  tables  and  contents 
of  all  the  current  databases.  The  team  has  created  an  “AS-IS”  architectural 
model  to  be  used  as  a  baseline  for  improvements  (Appendix  1). 


Long-Term  Recommendations 

5.  Migrate  “stand-alone”  information  files  into  the  overall  framework  of 
AFIT’s  information  management  strategic  plan. 

The  result  of  the  migration  is  intended  to  be  a  common  pool  of  managed 
data,  with  little  duplication,  and  easier  access.  The  use  of  query  language 
interfaces  to  this  pool  of  information  will  enable  the  staff  to  quickly  generate 
reports  or  temporary  tables  on  which  to  base  documents  created  previously 
by  a  word  processing  or  spreadsheet  application  (for  example.  Word  or 
Excel). 

6.  Develop  an  Executive  information  System. 

Since  an  EIS  presupposes  that  the  information  to  be  accessed  currently 
exists  in  a  carefully  managed  system  or  systems,  it  is  important  that  AFIT’s 
information  systems  be  up-to-date  and  accurate.  The  team  recommends 
adoption  of  the  “TO-BE”  model  with  multiple  applications  using  common 
interfaces  to  relational  databases  with  normalized  tables. 
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Other  Recommendations 

The  systems  analysis  and  design  team  has  been  asked  what  it  can 
contribute  to  helping  AFIT  achieve  the  recommendations  addressed  in  this 
report.  In  the  area  of  training  and  education,  the  team  can  provide  background 
information  gathered  and  facilitate  the  AFIT  personnel  assigned  to  the  training 
and  education  task. 

The  team  can  assist  in  establishing  guidelines  for  the  draft  operating 
instructions  or  directives.  Regarding  the  phased  approach  for  front-end 
applications,  the  team  can  assist  with  systems  analysis  and  design  and  perhaps 
in  prototyping  new  front  ends  for  some  applications. 

The  team  could  also  assist  with  the  design  and  integration  of  any  data 
models  required  as  AFIT  models  its  architecture.  Moreover,  the  team  could 
provide  some  direction  and  guidance  from  the  focal  point  of  individuals  who  have 
gathered  the  data  for  the  “AS-IS”  model.  The  team  could  also  assist  in 
developing  guidelines  for  the  responsibilities  of  data  administrator  and  database 
administrator.  Lastly,  the  team  could  also  assist  in  developing  requirements  or 
other  information  necessary  for  the  EIS  project. 

We  urge  the  Commandant  to  implement  the  near-term  recommendations  as 
quickly  as  possible  to  improve  the  productivity  and  efficiency  of  AFIT’s 
management  of  information.  The  intermediate  and  long-term  recommendations 
should  be  included  in  AFIT’s  future  plans  to  provide  maximum  opportunity  for 
completion  of  the  tasks. 

We  would  like  to  thank  the  AFIT  faculty  and  staff  for  their  time  and  for 
providing  the  necessary  inputs  to  complete  our  report. 
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(See  accompanying  Microsoft  PowerPoint  4  file 
AP-MODEL.PPT 
for  Appendix  1  to  the  report) 
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Equivalency  Exam  System  (EES) 
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AFIT’s  Civilian  Education  System  (ACES) 
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Acronyms  and  Definitions 


ACES  -  AFIT's  Civilian  Education  System.  Includes  MIFFS  and  FEDS. 

Access  -  Relational  database  management  system  (RDBMS)  by  Microsoft  ®.  Software  with  the  ability  to 
create  and  manipulate  databases. 

ACQMAN  -  Financial  software  used  by  the  library  (LD).  Its  use  is  mandated  by  Central  AF  Services. 
Operates  through  the  integrated  software  package  known  as  Enable  ®. 

ADAMS  -  Academic  Data  And  Mass  Storage. 

ADPE  -  Automated  Data  Processing  Equipment. 

AFITSIS  -  AFIT  Student  Information  System.  Includes  STARS,  QUEST  (QUOTA),  ISA,  MSI,  and  MSQ. 
AFPC  -  Air  Force  Personnel  Center. 

AFTMS  -  Air  Force  Training  Management  System 

APS  -  AFIT  Personnel  Management  System  (formerly  PMS) 

ASAS  -  Automated  Space  Allocation  System. 

ATRRS  -  Army  Training  Resource  and  Requirements  System. 

ATLAS  -  The  Headquarters  Air  Force  (HAF)  information  retrieval  system.  A  structured  query  language 
(SQL)  used  to  access  data  in  PC-lIl. 

AUOP  -  Air  University  Operating  Plan. 

CMDS  -  CoMmand  Database  System. 

COBOL  -  common  Business  Oriented  Language. 

Configuration  Control  Board  (CCB)  -  A  formally  constituted  board  where  members  are  assigned  specific 
program  and  project  responsibility.  The  CCB  will  make  decisions  on  major  changes  to  established 
software,  automated  data  processing  equipment,  and  documentation  baselines. 

Context  Diagram  -  Overview  data  flow  diagram  depicting  an  entire  system  as  a  single  process  with  its 
major  inputs  and  outputs. 

Data  Administrator  -  An  organizational  function  responsible  for  database  planning  and  for  establishing 
policies  for  accessing  and  maintaining  databases. 

Database  Administration  -  An  organizational  function  responsible  for  the  technical  aspects  of  establishing 
and  maintaining  databases,  in  line  with  the  policies  laid  down  by  the  data  administrator. 

Data  Flow  Diagram  (DFD)  -  A  graphic  representation  of  the  flow  of  data  throughout  a  system. 
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Data  Flows  -  The  movement  of  data  between  processes,  external  entities,  and  data  stores  in  a  data  flow 
diagram. 

Data  Stores  -  Manual  or  automated  inventories  of  data. 

dBase  5  -  A  RDBMS  by  Borland  ®.  Software  with  the  ability  to  create  and  manipulate  databases. 

DBMS  -  DataBase  Management  System. 

DIN  -  Data  Identification  Number.  Used  in  PC-111  applications. 

EES  -  Equivalency  Exam  System 

EIS  -  Executive  Information  System.  Information  systems  which  provide  higher-level  managers  with 
direct  and  easy  access  to  aggregated  information  and  detailed  data. 

ENDB  -  AFIT/EN  Database  Applications. 

Excel  -  Spreadsheet  application  from  Microsoft  ®. 

FEDS  -  Financial  Expense  Data  System.  Subsystem  of  ACES. 

Fourth  Generation  Language  -  A  very-high-level  programming  language  that  permits  the  programmer  or 
user  to  specify  what  is  wanted  from  the  computer  rather  than  how  this  should  be  obtained.  Many  of  these 
languages  are  directly  employed  by  end  users. 

GDSS  -  Group  Decision  Support  System  -  Information  systems  designed  to  support  group  communications 
and  decision  processes. 

GUI  -  Graphical  User  Interface.  A  user  interface  that  relies  on  Windows,  cursor-control  devices  (for 
example,  a  mouse),  icons,  and  menus  instead  of  verbal  commands. 

IPMS  -  Information  Processing  Management  System.  Stores  ADPE  data  for  the  Air  Force.  The  IPMS 
database  is  located  at  Gunter  AFB. 

ISA  -  International  Student  Affairs.  Subsystem  of  AFITSIS. 

MIFFS  -  Mgt  Information  Financial  Forecasting  System.  Subsystem  of  ACES. 

MSI  -  Mission  Support  Information.  Subsystem  of  AFITSIS. 

MSQ  -  MSQ  Orderly  Functions.  Subsystem  of  AFITSIS. 

OCMAN  -  Financial  software  used  by  the  library  (LD).  Its  use  is  mandated  by  Central  AF  Services. 
Operates  through  the  integrated  software  package  known  as  Enable  ®. 

Oracle  -  A  commercial  RDBMS  incorporating  the  SQL  data  access  language. 

Paradox  -  A  database  application  and  development  system  available  in  DOS  and  Windows. 

PC-III  -  Personnel  Concept  3.  The  Air  Force’s  Personnel  data  system  (PDS)  which  has  the  capability  to 
store,  update,  and  retrieve  data  on  all  Air  Force  personnel.  The  system  has  a  direct  link  to  AFPC.  The 
PSM  is  in  charge  of  maintaining  the  system.  AFIT’s  PSM  is  located  in  RRA. 
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PC-IPMS  -  Personal  Computer  Information  Processing  Management  System.  SC  uses  PC-IPMS  to  update 
local  IPMS  database  which  contains  ADPE  data.  Periodically,  PC-IPMS  is  used  to  electronically  update 
the  Air  Force’s  host  IPMS  database  which  is  located  at  Gunter  AFB. 

PDS  -  Personnel  Data  System. 

PowerPoint  -  Presentation  graphics  program  by  Microsoft  ®. 

PROTRAC  -  Project  Tracking  system  developed  by  SC. 

PSM  -  Personnel  Systems  Manager.  Individual  in  charge  of  maintaining  PC-III.  AFIT’s  PSM  is  located  in 
RRA. 

RDBMS  -  Relational  DataBase  Management  System. 

Query  Language  -  A  fourth-generation  language  for  retrieving  data  from  databases. 

QUEST  -  QUota  Education  &  Selection  Transactions  (a.k.a.  QUOTA) .  Subsystem  of  AFITSIS. 

SQL  -  Structured  Query  Language. 

STARS  -  STudent  Records  System.  Subsystem  of  AFITSIS. 

Synonyms  -  An  alias  for  a  table,  view,  sequence,  or  program. 

Table  -  A  basic  unit  of  storage  in  an  ORACLE  database. 

View  -  A  custom-tailored  presentation  of  the  data  in  one  or  more  tables. 

Word  -  Word  processing  application  by  Microsoft  ®. 
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APPLICATIONS 


ACES  -  AFlT's  Civilian  Education  System.  Includes  MIFFS  and  FEDS. 

ACQMAN  -  Financial  software  used  by  the  library  (LD).  Its  use  is  mandated  by  Central  AF  Services. 
Operates  through  the  integrated  software  package  known  as  Enable  ®. 

ADAMS  -  Academic  Data  And  Mass  Storage. 

AFITSIS  -  AFIT’s  Student  Information  System.  Includes  STARS,  QUEST  (QUOTA),  ISA,  MSI,  and 
MSQ. 

AFTMS  -  Air  Force  Training  Management  System 
APS  -  AFIT  Personnel  Mgt  System  (formerly  PMS) 

ASAS  -  Automated  Space  Allocation  System. 

ATLAS  -  The  Headquarters  Air  Force  (HAF)  information  retrieval  system.  A  structured  query  language 
(SQL)  used  to  access  data  in  PC-III. 

ATRRS  -  Army  Training  Resource  and  Requirements  System. 

CMDS  -  CoMmand  Database  System. 

EES  -  Equivalency  Exam  System 
ENDB  -  AFIT/EN  Database  Applications. 

Excel  -  Spreadsheet  application  from  Microsoft  ®. 

FEDS  -  Financial  Expense  Data  System.  Subsystem  of  ACES. 

IPMS  -  Information  Processing  Management  System.  Stores  ADPE  data  for  the  Air  Force.  The  IPMS 
database  is  located  at  Gunter  AFB. 

ISA  -  International  Student  Affairs.  Subsystem  of  AFITSIS. 

MIFFS  -  Mgt  Information  Financial  Forecasting  System.  Subsystem  of  ACES. 

MSI  -  Mission  Support  Information.  Subsystem  of  AFITSIS. 

MSQ  -  MSQ  Orderly  Functions. .  Subsystem  of  AFITSIS. 

OCMAN  -  Financial  software  used  by  the  library  (LD).  Its  use  is  mandated  by  Central  AF  Services. 
Operates  through  the  integrated  software  package  known  as  Enable  ®. 

PC-IPMS  -  Personal  Computer  Information  Processing  Management  System.  SC  uses  PC-IPMS  to  update 
local  IPMS  database  which  contains  ADPE  data.  Periodically,  PC-IPMS  is  used  to  electronically  update 
the  Air  Force’s  host  IPMS  database  which  is  located  at  Gunter  AFB. 
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PowerPoint  -  Presentation  graphics  program  by  Microsoft  ®. 

PROTRAC  -  Project  Tracking  system  developed  by  SC. 

QUEST  -  QUota  Education  &  Selection  Transactions  (a.k.a.  QUOTA) .  Subsystem  of  AFITSIS. 
STARS  -  STudent  Records  System.  Subsystem  of  AFITSIS. 
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DATABASE  MANAGEMENT  SYSTEMS 


Access  -  Relational  database  management  system  (RDBMS)  by  Microsoft  ®.  Software  with  the  ability  to 
create  and  manipulate  databases. 

dBase  5  -  A  RDBMS  by  Borland  ®.  Software  with  the  ability  to  create  and  manipulate  databases. 

Oracle  -  A  commercial  RDBMS  incorporating  the  SQL  data  access  language. 

Paradox  -  A  database  application  and  development  system  available  in  DOS  and  Windows. 

PC-III  -  Personnel  Concept  3.  The  Air  Force’s  Personnel  Data  System  (PDS)  which  has  the  capability  to 
store,  update,  and  retrieve  data  on  all  Air  Force  personnel.  The  system  has  a  direct  link  to  AFPC.  The 
PSM  is  in  charge  of  maintaining  the  system.  AFIT’s  PSM  is  located  in  RRA. 
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APPENDIX  4 


DRAFT  REGULATIONS 


DEPARTMENT  OF  THE  AIR  FORCE  AFIT  REGULATION  7  00-? 

Air  Force  Institute  of  Technology 

Wright-Patterson  AFB  OH  45433  24  Feb  94 

COMMUNICATIONS-COMPUTER  SYSTEMS  '  ^  v 

ESTABLISHMENT  OF  AFITDB  CONFIGURATION  CONTROL  BOARDS  ^ 

This  regulation  defines  the  policy,  process,  and  responsibility 
for  conducting  the  AFIT  Configuration  Control  Board  and 
Configuration  control  Sub-Boards  for  all  software  associated  with 
AFIT/SC  managed  corporate  databases  (AFITDB)  and  all  AFIT/SC 
managed  automated  data  processing  equipment  (ADPE)  .  The  provisions 
of  this  regulation  relate  to  all  personnel  having  software  or  ADPE 
that  falls  under  the  control  and  responsibility  of  AFIT/SC. 

1 .  REFERENCES  ; 

a.  AFITDB  SOFTWARE  CONFIGURATION  MANAGEMENT  PLAN 

b.  AFR  14-1  CONFIGURATION  MANAGEMENT 

C.  AFR  7  00-4  COMMUNICATIONS-COMPUTER  SYSTEMS  PROGRAM 
MANAGEMENT 

2 .  PURPOSE  : 


a.  This  regulation  governs  users  of  subsystems  or 
databases  that  makeup  the  AFIT/SC  managed  AFITDB  and  all 
AFIT  ADPE.  Procedures  outlined  herein  provide  AFIT 
organizations  a  method  to  request  a  change  or  enhancement 
to  a  system,  obtain  needed  feedback  on  the  change,  and 
obtain  official  approval  so  that  the  change  may  be 
incorporated  into  the  subsystem. 

b.  The  objectives  behind  the  establishment  of  the 
configuration  management  control  boards,  to  include  the 
sub-boards,  are; 

1)  to  provide  a  simple,  organized  method  for  the 
approval/validation  of  all  changes  made  to  systems 
within  AFITDB, 

2)  to  ensure  system  integrity  is  maintained  while 
incorporating  new  software  or  hardware  to  all 
sxibsystems , 

3)  to  prioritize  requirements  based  upon  mission 
criticality,  manpower,  and  urgency  of  need. 
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CONTIGURXTIOH  KAHAGKK^IIT  PROCEDURE 


Title  :  Configuration  Control  Board 

This  procedure  defines  the  policy,  process,  and  responsibility 
for  conducting  the  Configuration  Control  Board  (CCB)  and 
Control  Sub-boards  (SCCSB)  for  all  AFIT  Automated 
SSl  P?oci^ing  E<3uipment  (ADPE)  and  AFIT  Database  (AFITDB) 
softwaS  The  provisions  of  this  procedure  apply  to  all  personnel 
usi^r  dSvelopiM,  or  testing  software  that  falls  under  the  control 
of  l^ITDB,  and  personnel  planning  to  use  and  using  ADPE  within 
IfIT  This  is  an  incremental,  detailed  procedure  relatinj 
AFIT  software  Configuration  Management  Plan  (SCMP)  and  the  five- 
vear  communications-Computer  Systems  (CCS)  Assessment  (draft). 
Both  of  these  documents  are  managed  by  AFIT/SC. 


1.  explanation  of  TERMS; 

a  Configuration  Management  (CM)  ;  A  discipline  applying 
technical  and  administrative  direction  and  surveillance  to 

identify  and  document  the  functional  and  physical 
characteristics  of  a  configuration  item, 


(2)  control  changes  to  those  characteristics,  and 

(3)  record  and  report  change  processing  and 
implementation  status . 

In  this  procedure,  the  configuration  management  office  (CMO) 
will  be  AFIT/SCV . 


b.  configuration  Control  Board  (CCB) :  A  formally  constituted 
board  within  AFIT.  Members  are  assigned  specific  program  and 
project  responsibility.  The  CCB  will  make  decisions  on  ma^ or 
changes  to  established  software,  ADPE,  and  documentation  baselines. 

/^This  board  will  meet  to  make  decisions  that  cannot  be  made  at  the 
sub— board  level. 

c.  Software  Configuration  Control  Sub-boards  (SCCSB) ;  A 

formally  constituted  board  within  AFIT  having  members  with  specific 

N.  program^and  project  responsibility  which  will  provide  decisions 
^  ?oSrolling  changes  to  the  established  software  baselines. 

d  Hardware  Configuration  Control  Sub-boards  (HCCSB)  ;  A 
formally  constituted  board  within  AFIT  having  members  with  specific 
program  and  project  responsibility  which  will  provide  decisions  in 
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controlling  changes  to  the  established  ADPE  baselines. 

e.  Communications-Computer  Systems  Requirement  Document 
(CCSRD)  AF  Form  3215:  This  form  will  be  used  to  propose  a  class  I 
(major)  change  to  the  existing  software  or  ADPE  baseline.  It 
describes  the  proposed  change  and  it's  impact  on  cost,  schedule, 
and  performance  of  the  subsystems  involved.  This  form  is  also  used 
for  changes  that  result  in  a  new  capability. 

f.  Software  system  Enhancement  Request  (SSER) :  The  SSER 
describes  a  class  II  (minor)  software  change  or  a  discrepancy  or 
deficiency  in  a  given  software  application.  It  is  an  aut6m^:^ed 
form  accessed  from  electronic  mail .  An  SSER  is  not  used  ^.^^^or 
changes  that  result  in  a  new  capability. 

g.  ADPE  System  Enhancement  Request  (ASER)  :  The  ASER 
describes  a  class  II  (minor)  hardware  change  or  a  discrepancy  or 
deficiency  in  any  given  ADPE.  It  is  an  autoTSated  form  accessed 
from  electronic  mail.  An  ASER  is  not  used  for  changes  that 
result  in  a  new  capability.  _ _ _ - 

h.  Configuration  Item:  The  smallest  unit  tracked  for 
configuration  management  (e.g.  software  functions  or  applications, 
printers,  network  servers) 

i.  Change  Class:  A  Class  I  change  effects  the  form,  fit, 
and/or  function  of  a  configuration  item  (i.e.  software  upgrade,  new 
mother  board)  .  A  Class  II  change  is  minor  in  nature  and  does  not 
impact  the  form,  fit  and/or  function  of  a  configuration  item.  (i.e. 
a  typographical  error  in  software,  a  cable  change) 

j.  Change  Notice:  Generic  name  for  a  CCSRD,  ASER,  or  SSER. 
Used  when  a  specific  type  of  form  doesn't  need  to  be  addressed. 

k.  Svimmary  of  Change:  This  section  is  located  at  the  end  of 
the  document  and  reflects  all  past  changes  made  to  this  document. 

l.  Configuration  Control  Board  Directive  (CCBD) :  formal 
written  effect/recommendation/concurrence  of  a  CCB  meeting  signed 
by  the  CCB  Chairperson. 

m.  Management  Information  Financial  Forecasting^  System 
(MIFFS)  .  MIFFS  provides  education  tracking  and  financial 
information  for  students  attending  civilian  institutions.  MIFFS 
contains  the  following  subsystems: 

(1)  AFIT  civilian  Education  System  (ACES).  ACES  is  a 
management  information  system  that  is  used  to  maintain  information 
concerning  students  assigned  to  Civilian  Institution  Programs  (Cl) , 
the  civilian  institutions  students  attend,  and  the  programs  and 
progrcun  offices  within  the  Directorate  of  Cl  to  which  the  students 
are  assigned.  ACES  was  developed  so  that  Cl  staff  can  quickly 
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generate  management  reports,  can  track  forms  and  other  paperwork, 
can  schedule  training  reports,  and  can  generate  statistical 
information  concerning  Cl  students  and  programs. 

(2)  Resources  Commercial  Services  Directorate  (RPBD) 
Financial  Expense  Data  Systems  (FEDS).  FEDS  is  a  financial  data 
management  system  developed  to  enhance  the  interface  between  Cl  and 
RPBD.  FEDS  tracks  cost  data,  vouchers,  surveys,  agreements  between 
civilian  institutions  and  AFIT,  budget  estimations,  and  other 
financial  information.  FEDS  is  closely  tied  to  the  ACES  data 
tables . 


n.  AFIT  Student  Information  System  (AFITSIS)  .  AFITSIS  is  a 
series  of  database  application  packages  designed  to  integrate 
school  related  functions  into  a  centralized  database.  AFITSIS 
concentrates  on  functions  associated  with  the  resident  graduate 
education  students.  It  currently  provides  information  and 
functions  for  in-processing,  registration,  educational  planning, 
scheduling  course  offerings,  grading,  international  student 
affairs,  and  publishing  graduation  transcripts.  AFITSIS  contains 
the  following  subsystems; 


(1)  Student  Tracking  and  Registration  System  (STARS)  is 
designed  to  maintain  AFIT  student  information  from  admittaij^  to 
graduation.  Student  records  are  accessible  to  the 

office,  the  School  of  Systems  and  Logistics,  and  the^^chool  of  — 
Engineering.  The  registrar's  office  uses  the  system_tja-aaintain 
educational  history  necessary  to  produce  a  transcript.  The  schools 
have  the  capability  to  view  the  information  entered  by  the 
registrar  pertaining  to  their  school  only  and  also  to  create  and 
modify  ed— plans  and  thesis  data  for  a  student. 


(2)  AFIT  Orderly  Room  System  (CCQ)  is  designed  to 
maintain  information  applicable  to  the  functions  of  the  orderly 
room,  this  includes  box  numbers,  locker  numbers,  se^ion  leaders, 
security  access  badges,  building  access  codes,  Lweigh- in  and 
physical  training  data,  weight  management  program  statistics, 
emergency  locator  informationJ  and  other  student  information.  CCQ 
produces  student  information -^eets,  alpha  rosters,  section  leader 
rosters,  book  allowance  listings,  and  mailing  labels. 

(3)  International  Student  Affairs  (ISA)  is  designed  to' 
maintain  information  of  the  international  military  students 
attending  AFIT.  This  includes  family,  fxinding,  sponsor,  and 
informational  progr2ua  data. 

(4)  C|^ta  Education  and  Selection  Transactions  (QUEST)  is 
designed  to  tr^k  and  maintain  information  related  to  a  student 
selection  for  an  AFIT  or  Civilian  Institution  (Cl)  program.  It 
associates  a  student  with  a  quota  set  by  the  Air  Education  Training 
Command  (AETC)  .  Records  for  student  selected  for  an  AFIT  program 
are  accessible  through  STARS  and  CCQ.  Records  for  students 
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selected  for  a  Cl  program  are  accessible  through  ACES. 

(5)  Equivalency  Exam  System  (EES)  is  designed  to  track 
students  who  take  various  exams  offered  by  AFIT. 

o.  (ASAS) - r?  UL-. 

p.  AFIT  Personnel  System  (APS). —  ^ 

2.  POLICY:  , 

a.  Scope:  The''*^C^ii’''an  official  advising  Air  Force  group 
established  by  AFIT/SC.  •  It  is  the  official  agent  responsible  to 
act  on  all  class  I  -Xiwt^or)  changes  and  the  baselining  of  AFITDB 
software  subsystems  and  ADPE. 

b.  CCB  Authority:  Each  member  of  the  CCB  is  responsible  for 

representing  their  functional  area's  position  on  each  Class  I 
change  to  the  system.  The  CCB  Chairperson,  or  alternate,  has  the 
authority  to  approve  or  disapprove  all  software  or  ADPE  changes 
presented  to  the  board.  Members  in  attendance  will  certify  their 
official  position  relative  to  the  decision  of  the  Chairperson  by 
indicating  either  a  concurrence  or  non-concurrence  on  the 
configuration  control  board  directive  (CCBD) .  Should  a  non¬ 
concurrence  occur  and  a  compromise  cannot  be  reached  in  the  CCB 
meeting,  the  dissenting  member  (s)  may  sxibmit  a  written 
non-concurrence  report  to  the  Chairperson,  along  with  an 
information  cop^to  the'^0,  within  three  working  days  subsequent 
to  the  meeting.  ^The  Chairperson  will  review  the  report  and  make  a 
decision  before  implementation  of  the  CCBD.”\— =)  ^ 

c.  CCB  Official  Membership:  The  following  members  constitute 
the  AFIT  CCB: 

(1)  Software 

(a)  Chairperson:  AFIT/CF  (HORNER) 

(b)  ACES/MIFFS  Member:  AFIT/CI 

(c)  ACES/FEDS  Member:  AFIT/FM 

(d)  AFITSIS  Member:  AFIT/CV 

(e)  EES  Member:  AFIT/LS 

(f)  ASAS  Member:  AFIT/LS 

(2)  ADPE 

(a)  - ^  ul*  hi' 
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(b) 


(3)  Secretary:  CMO  (AFIT/SC)  or  assigned  CM 

representative  for  AFIT/SC. 

(4)  Other  members  and  their  alternates  placed  on  this 

board  will  be  appointed  in  writing.”^-^  i>./  “ 

d.  Limitations/Constraints:  The  CCS  will  meet  on  an 

"as-needed”  basis.  The  board  will  convene  only  when  Class  I 
changes  are  proposed  and  cannot  be  decided  upon  by  the  Sub-board (s) 
involved  or  .a  proposed  change  involves  strategic  goals  of  AFIT. 

e.  Criteria  for  Change  Approval;  Only  changes  which  meet  the 
following  criteria  will  be  considered  for  approval: 

(1)  Changes  necessary  to  correct  a  deficiency  in  a  given 
subsystem. 

(2)  Changes  which  will  significantly  increase  the 
effectiveness  or  the  operational  performance  of  the 
system. 

(3)  Changes  to  make  the  system  and/or  configuration 
items  compatible  with  other  approved  changes. 

3.  CCB  PROCEDURE. 

a.  All  CCSRDs,  ASERs,  and  SSERs  (change  notices)  will  be 
routed  to  the  AFIT/SC  help  desk  for  logging  and  tracking  by  the 
CMO. 


b.  The  CMO  will  determine  which  CCSRDs  are  Class  I  and 
require  CCB  action  and  which  SSERs/ ASERs  are  Class  II  and  reguire 
SCCSB  or  HCCSB  action. 

c.  A  CCB  formal  agenda  listing  all  proposed  change  notices 
vill  be  prepared  and  distributed  by  the  CMO  not  later  than  three 
days  prior  to  the  scheduled  board  meeting. 

d.  Routine  change  notices  will  normally  be  scheduled  to  allow 
CCB  members  25  days  for  review.  Urgent  change  notices  will  be 
scheduled  to  allow  CCB  members  15  working  days  for  review. 
Emergency  change  notices  will  receive  immediate  action. 

e.  CCB  Action:  All  scheduled  change  notices  will  be  reviewed 
by  the  CCB  with  the  Chairperson's  decision  documented  in  the  CCBD. 
CCB  proceedings  will  not  be  considered  final  until  the  CCBD  has 
been  signed  by  the  CCB  Chairperson.  The  following  options 
regarding  disposition  of  change  notices  are  available  to  the  CCB 
Chairperson: 
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1)  Approved  as  written. 

2)  Disapproved.  (Reason  for  disapproval  to  be  provided  in 
the  comments  of  the  CCBD) 

3)  Approved  with  comments.  (All  comments  will  be 
documented  in  the  CCBD) 

4)  Deferred  for  further  investigation.  The  deferred 
change  will  be  acted  upon  at  the  next  CCB.  The  CMC  and 
drafter  of  the  proposed  change  notice  will  perform  the 
investigation. 

f.  Optional  Processing  Procedures:  The  CCB  Chairperson  may 
authorize  a  walk  through  procedure  to  process  a  change  notice  which 
has  an  emergency  program  impact.  The  CMO  will  hand  carry  the 
signed  CCBD  to  obtain  a  coordinated  position  from  the  CCB  members. 
Items  may  be  processed  by  the  CCB  Chairperson  with  coordination  of 
only  CCB  members  whose  organizations  are  affected  by  the  change. 

g.  CCB  Meetings: 

1)  Meetings  will  normally  be  scheduled  as  needed  by  the 
CMO.  However,  the  CCB  Chairperson  may  call  a  special 
meeting  at  any  time,  date,  and  place  where  deemed 
necessary  to  meet  system  requirements.  When  a  primary 
representative  or  designated  alternate  is  not  present  at 
the  CCB  to  sign  the  CCBD(s)  ,  and  the  CCB  member  has  not 
communicated  his/her  position,  the  Chairperson  will 
assume  a  negative  reply  to  the  change  and  the  form  will 
be  left  blank.  When  attendance  is  not  possible,  the 
member  is  responsible  for  communicating  his/her  position 
on  the  change  to  the  Chairperson. 

2)  Action  items  may  be  assigned  by  the  Chairperson  to 
resolve  unanswered  questions  concerning  the  change  before 
the  board  makes  a  recommendation  for  final  disposition. 
All  CCB  actions  will  become  part  of  the  official  CCB 
meeting  minutes. 

4.  Responsibilities: 

a-  CCB  Chairperson: 

1)  Will  approve/ disapprove  the  agenda  provided  by  the 
CMO. 


2)  Presides  over  all  CCB  meetings  or  designate  an 
alternate  in  writing. 

3)  Determine  the  disposition  of  all  change  notices 
reviewed  by  the  CCB. 
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b.  CCB  Members  (or  designated  alternates) : 

1)  Provide  a  recommendation  or  a  negative  reply  on  the 
pre-board  Review  Sheets  (Attachment  1)  to  the  OPR  on  the 
attached  change  notice  not  later  than  2  days  prior  to 
the  board  date.  Provide  a  copy  of  the  Pre-Board  Review 
Sheet  to  the  CMO. 

2)  Reviews  agenda  and  returns  to  the  CMO  no  later  than 
two  days  before  the  CCB  meeting. 

3>  Will  attend  CCB  meetings. 

c.  Office  of  Primary  Responsibility  (OPR) : 

1)  Is  assigned  by  the  CMO  based  on  the  subject  and 
nature  of  the  change  notice.  This  OPR  will  be  identified 
on  the  CCB  agenda  and  the  Pre-board  review  sheet  (see 
Attachment  1)  . 

2)  Must  become  completely  familiar  with  all  aspects  of 
the  change  notice  assigned  to  him/her. 

3)  Coordinates  with  the  CMO  and  Chairperson  to  determine 
a  meeting  date. 

4)  Will  review  all  pre-board  review  sheet  comments  from 
board  members  prior  to  the  CCB. 

5)  will  present  the  change  notice  at  the  CCB.  The 
presentation  will  cover  all  relevant  aspects  of  the 
change  notice. 

d.  Configuration  Management  Office  (CMO): 

1)  Assigns  an  OPR  based  on  the  nature  and  subject  of  the 
change  notice . 

2)  Contacts  the  OPR  and  Chairperson  and  establistfa  board 
date  based  upon  the  urgency  of  the  change  (see  paragraph 
3 .d  above) . 

3)  Completes  the  Pre-board  Review  Sheet  down  to  the 
suspense  date  on  the  form  and  attaci^the  associated 
change  notice.  The  Pre-board  Review  sheet  and  the  change 
notice  make  a  complete  change  package  for  copying  and 
distribution.  A  copy  of  each  change  package  will  be  given 
to  each  CCB  member  unless  otherwise  specified  by  the 
Chairperson.  Each  OPR,  if  not  already  a  member  of  the 
CCB,  will  receive  a  copy  of  his/her  change  slated  for 
board  action.  The  distribution  time  frame  will  be  in 
accordance  with  the  urgency  of  change.  A  routine  change 
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will  be  distributed  no  later  than  25  days  prior  to  the 
board  meeting.  An  urgent  change  will  be  distributed-no 
later  than  15  days  prior  to  the  board  meeting,  iy^d*  ^ 
emergency  change  will  be  distributed  no  later  Vthap^S 
hours  prior  to  the  board  meeting  unless  an  OpEl^al 
Processing  Procedure  is  used  (paragraph  3f) . 

4)  Prepares  the  CCB  agenda  and  provides  the  agenda  to 
the  Chairperson  for  approval  when  required.  Issues  the 
agenda  to  all  CCB  members  and  OPRs  at  least  five  days 
prior  to  the  CCB. 

5)  Reviews  the  agenda  with  the  OPR(s)  two  days  before 
the  board  and  advises  the  CCB  chairperson  of  pre-board 
actions  to  add,  drop,  or  defer  change  notices  to/from  the 
agenda . 

6)  Distributes  the  presentation  materials  provided  by 
the  OPR  to  CCB  attendees  the  day  before  the  board  is  to 
convene . 

7)  Maintains  a  permanent  record  and  backup  file  of  all 
change  notice  activity. 

8)  Acts  as  Secretary  by  preparing  CCBDs  prior  to  the 
board  meeting  for  each  change  disposition  and  will  take 
minutes  in  accordance  with  the  direction  given  by  the  CCB 
Chairperson. 

9)  Tracks  all  Action  Items  from  initial  CCB  action  to 
closure  (see  Attachment  3) . 

5.  Configuration  Control  Sub-Boards  (SCCSB,  HCCSB)  Procedure 
a.  Policy: 

(1)  Scope;  The  SCCSB  and  HCCSB  are  official  advising  Air 
Force  groups  established  by  AFIT/SC.  They  are  the 
official  agents  responsible  to  act  on  both  class  I 
(major)  and  class  II  (minor)  changes  that  do  not  affect 
other  AFITDB  subsystems,  existing  ADPE,  or  the  baselining 
of  AFITDB  software  sxibsystems. 

(2)  SCCSB/HCCSB  Authority:  Each  member  of  the 
SCCSB/HCCSB  is  responsible  for  representing  their 
functional  area's  position  on  all  proposed  changes  to  the 
system.  The  SCCSB/HCCSB  Chairperson,  or  alternate,  has 
the  authority  to  approve  or  disapprove  all  software 
changes  presented  to  the  board.  Members  in  attendance 
will  certify  their  official  position  relative  to  the 
decision  of  the  Chairperson  by  indicating  either  a 
concurrence  or  non-concurrence  on  the  configuration 
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control  board  directive  (CCBD) .  Should  a  non¬ 

concurrence  occur  and  a  compromise  cannot  be  reached  in 
the  CCB  meeting,  the  dissenting  member (s)  may  submit  a 
written  non-concurrence  repoirt  to  the  Chairperson,  along 
with  an  information  copy  to  the  CM(^  within  three  working 
days  subsequent  to  the  meeting. /'The  Chairperson  will 
review  the  report  and  make  a  decision  before 

implementation  of  the  CCBD.^ 

(3)  SCCSB  Official  Membership:  '  *  • 

AFITSIS  Sub-Board:  1)  Chairperson:  AFIT/CV  or  alternate 

2)  Subsystem  Representatives;  STARS 

(AFIT/RR) ,  QUEST  (AFIT/RRZ) ,  ISA  (AFIT/RRI) , 

CCQ  (AFIT/MS) ,  EES  (AFIT/LA) . 

3)  CM  Representative 

MIFFS  Sub-Board;  1)  Chairperson:  AFIT/CI  or  alternate 

2)  Subsystem  Representatives:  ACES  (AFIT/CI), 
FEDS  (AFIT/FM) . 

3)  CM  Representative 

(4)  HCCSB  Official  Membership: 

xxxx . 

b.  Limitations/Constraints:  Changes  will  not  be  incorporated 
into  the  production  copy  of  the  subsystem  prior  to  SCCSB/HCCSB 
approval  of  a  change  notice. 

(1)  Criteria  for  Change  Approval; 

(a)  Only  changes  which  meet  the  following 
criteria  will  be  considered  for  approval; 

(1)  Changes  necessary  to  correct  a 
deficiency  in  a  given  subsystem. 

(2)  Changes  which  will  significantly 
increase  the  effectiveness  of  the  operational 
performance  of  the  subsystem. 

(3)  Changes  to  make  the  sxibsystem  and/or 
configuration  items  compatible  with  other 
approved  changes. 

c.  SCCSB/HCCSB  Procedure 

1)  All  change  notices  which  require  SCCSB/HCCSB  action 
will  be  routed  to  the  Configuration  Management  Office 
(CMO)  for  logging  and  tracking. 
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2)  Change  notices  will  be  processed  according  to 
urgency . 

3)  SCCSB/HCCSB  Action:  All  scheduled  change  notices 
will  be  reviewed  by  the  SCCSB/HCCSB  with  the 
Chairperson's  decision  docximented  in  the  CCBD. 
SCCSB/HCCSB  proceedings  will  not  be  considered  final 
until  the  CCBD  has  been  signed  by  the  SCCSB/HCCSB 
Chairperson.  The  following  options  regarding 
disposition  of  change  notices  are  available  to  the 
SCCSB/HCCSB  chaiiperson; 


a)  Approved  as  written. 

b)  Disapproved.  (Reason  for  disapproval  to  be 
provided  in  the  comments  of  the  CCBD) 

c)  Approved  with  comments.  (All  comments  will  be 
documented  in  the  CCBD) 

d)  Deferred  for  further  investigation.  The  deferred 
change  will  be  acted  upon  at  the  next  SCCSB/HCCSB 
or  CCB. 

e)  Passed  up  to  the  CCB  for  action  if  concurrence 
cannot  be  reached  or  the  change  affects  systems 
outside  the  scope  of  the  subsystem. 

4)  Optional  Processing  Procedures:  The  SCCSB/HCCSB 

Chairperson  may  authorize  a  walk  through  procedure  to 
process  a  change  notice  which  has  an  emergency  program 
impact.  The  CMO  will  hand  carry  the  signed  CCBD  to  obtain 
a  coordinated  position  from  the  SCCSB/HCCSB  members. 
Items  may  be  processed  by  the  SCCSB/HCCSB  Chairperson 
with  coordination  of  only  SCCSB/HCCSB  members  whose 
organizations  are  affected  by  the  change. 

5)  SCCSB/HCCSB  Meetings: 

a)  Meetings  will  normally  be  scheduled  as  needed 
by  the  CMO.  However,  the  SCCSB/HCCSB  Chaiiperson 
may  call  a  special  meeting  whenever  deemed 
necessary  to  meet  system  requirements.  When  a 
permanent  representative  or  designated  alternate 
is  not  present  at  the  SCCSB/HCCSB  to  sign  the 
CCBD(s)  ,  and  the  SCCSB/HCCSB  member  has  not 
communicated  his/her  position,  the  Chairperson  will 
assiime  a  negative  reply  to  the  change  and  the  form 
will  be  left  blank.  When  attendance  is  not 
possible,  the  member  is  responsible  for 

communicating  his/her  position  on  the  change  to  the 
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Chairperson. 


b)  Action  items  may  be  assigned  by  the  Chairperson 
to  resolve  unanswered  questions  concerning  the 
change  before  the  board  recommends  a  final 
disposition.  All  SCCSB/HCCSB  actions  will  become 
part  of  the  official  SCCSB/HCCSB  meeting  minutes. 

d.  Responsibilities: 

1)  Office  of  Primary  Responsibility  (OPR) : 

a)  Is  assigned  by  the  CMO  based  on  the  subject  and 
nature  of  the  change  notice.  This  OPR  will  be 
identified  on  the  SCCSB/HCCSB  agenda  and  the 
Pre-board  review  sheet  (see  Attachment  1)  . 

b)  Must  become  completely  familiar  with  all 
aspects  of  the  change  notice  assigned  to  him/her. 

c)  Coordinates  with  the  CMO  and  Chairperson  to 
determine  a  SCCSB/HCCSB  meeting  date. 

d)  Reviews  all  pre-board  review  sheet  comments 
from  board  members  prior  to  the  SCCSB/HCCSB. 

e)  Presents  the  change  notice  at  the  SCCSB/HCCSB. 
The  presentation  will  cover  all  relevant  aspects  of 
the  change  notice. 

2)  SCCSB/HCCSB  Chairperson: 

a)  Approves/disapproves  the  agenda  provided  by  the 
CMO. 

b)  Presides  over  SCCSB/HCCSB  meetings  or  designate 
an  alternate  in  writing. 

c)  Determines  the  disposition  of  all  change  notices 
reviewed  by  the  SCCSB/HCCSB. 

3)  SCCSB/HCCSB  Members  (or  designated  alternate): 

a)  Provide  a  recommendation  or  a  negative  reply  on 
the  pre-board  Review  Sheets  (Attachment  1)  to  the 
OPR  on  the  attached  change  notice  not  later  than  2 
days  prior  to  the  board  date.  Also,  a  copy  of  the 
disposition  form  must  be  returned  to  the  CMO. 

b)  Attend  SCCSB/HCCSB  meetings. 

4)  Configuration  Management  Office  (CMO) : 


11 


a)  Assigns  an  OPR  based  on  the  nature  and  subject 
of  the  change  notice. 

b)  Contacts  the  OPR  and  establish  a  board  date 
based  upon  the  urgency  of  the  change. 

c)  Completes  the  Pre-Board  Review  Sheet  down  to 
the  suspense  date  on  the  form  and  attach  the 
associated  change  notice.  The  Pre-Board  Review 
sheet  and  the  change  notice  make  a  complete  package 
for  copying  and  distribution.  A  copy  of  each 
change  package  will  be  given  to  each  SCCSB/HCCSB 
member  unless  otherwise  specified  by  the 
Chairperson.  Each  OPR,  if  not  already  a  member  of 
the  SCCSB/HCCSB,  will  receive  a  copy  of  his/her 
change  slated  for  board  action.  The  distribution 
time  frame  will  be  in  accordance  with  the  urgency 
of  change.  A  routine  change  will  be  distributed  no 
later  than  14  days  prior  to  the  board  meeting.  An 
urgent  change  will  be  distributed  no  later  than  7 
days  prior  to  the  board  meeting.  And,  an  emergency 
change  will  be  distributed  no  later  than  8  hours 
prior  to  the  board  meeting  unless  Optional 
Processing  Procedure,  or  walk  through,  is  used. 

d)  Prepares  the  SCCSB/HCCSB  agenda  and  provides 
the  agenda  to  the  Chairperson  for  approval  when 
required.  Issues  the  agenda  to  all  SCCSB/HCCSB 
members  and  OPRs  at  least  five  working  days  prior 
to  the  SCCSB/HCCSB. 

e)  Reviews  the  agenda  with  the  OPR(s)  the  day 
before  the  board  and  advises  the  SCCSB/HCCSB 
chairperson  of  pre-board  actions  to  add,  drop,  or 
defer  change  notices  to/ from  the  agenda. 

f)  Distributes  the  presentation  materials  provided 
by  the  OPR  to  SCCSB/HCCSB  attendees  two  days  before 
the  board  is  to  convene. 

g)  Maintains  a  permanent  record  and  backup  file  of 
all  change  notice  activity. 

h)  Acts  as  Secretary  by  preparing  CCBDs  prior  to 
the  board  meeting  for  each  change  disposition  and 
will  take  minutes  in  accordance  with  the  direction 
given  by  the  SCCSB/HCCSB  Chairperson. 

i)  Tracks  all  Action  Items  from  initial 
SCCSB/HCCSB  action  to  closure  (see  Attachment  2) . 
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Attachment  1:  Pre-Board  Review  Sheet 


Configuration  Control  Board  Pre-Board  Review  Sheet  (Item/Title)  for 

review  by _ .  CCB  Member,  or  his/her 

alternate  _ _ • 

1.  The  attached  item  is  forwarded  for  your  review  and  comments 
prior  to  CCB  action.  Please  send  this  form  with  your 
recommendation  and  applicable  comments  on  this  item  to  the  OPR 
noted  belowt 


2.  This  item  is  tentatively  scheduled  for  presentation  to  the  CCB 

on^ _ _ _ .  A  firm  date  and  agenda  will  be  distributed 

one  week  prior  to  the  meeting  of  the  CCB. 


(Chief,  Division  Name  or  CMO)  1  Atch 

AFIT 

1st  Ind  Date - 

To ;  OPR 

Copy;  AFIT/SCV  (CMO) 

Suspense  date_ _ 

Recommend :  Approval^ _  Disapproval _ 

Coxoments : 


Signature  of  CCB  member 
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Attachment  2 :  CCB  Action  Item 

CCB  Action  Item 

Date  Issued: 

Suspense: 

Initiator: 

To:  _ 

Subject:  _ 


Action  Item  #: 
Status: 

Date  Closed: 
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Summary  ot  Change  Section 
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DEPARTMENT  OF  THE  AIR  FORCE 

Air  Force  Institute  of  Technology  (AU) 

Wright-Patterson  AFB  OH  4  5433--6583 


AFIT  REGULATION  700-xx 
4  Sep  91 


Maintaining  the  AFIT  Database 

This  regulation  establishes  policy  and  responsibility  for 
maintaining  the  information  in  the  Air  Force  Institute  of 
Technology  (AFIT)  Management  Information  System  (MIS)  database  and 
applies  to  all  schools,  directorates,  and  staff  agencies  of  AFIT 
located  at  Wright-Patterson  AFB. 

1.  General:  The  AFIT  MIS  is  a  collection  of  interrelated  software 
applications  which  uses  a  centralized  database,  desigpied  to  meet 
the  varied  information  needs  of  the  Institute.  It  is  incumbent  on 
each  office  that  uses  the  database  to  keep  the  information  complete 
and  accurate  at  all  times. 

2.  Policy:  The  AFIT  MIS  will  be  used  to  maintain  data,  perform 
functions,  and  generate  reports  related  to  management  of  AFIT's 
resident  graduate  education  and  Civilian  Institution  Programs.  The 
MIS  will  be  the  primary  focus  for  student  information  from 
selection  to  graduation.  The  database  will  maintain  information 
concerning  student,  faculty  and  staff  personnel. 

3.  Responsibilities:  All  offices  that  use  the  database  shall 
share  the  responsibility  of  keeping  the  information  complete  and 
accurate.  This  regulation  will  define  in  general  terms  where  the 
responsibility  lies  for  most  student  related  information. 
Attachments  1  and  2  establish  data  requirements  and  the  Offices  of 
Primary  Responsibility  (OPRs)  for  information  updates. 

a.  The  Communications-Computer  Systems  Directorate,  SC. 

(1)  SC  will  have  ultimate  responsibility  for  the 
database  and  applications  used  the  manipulate  the  data.  A  project 
manager  will  oversee  the  development  of  applications  that  are  able 
to  change  data  in  the  database. 

(2)  At  the  discretion  of  the  project  manager,  other 
applications  may  have  access  to  the  database  in  a  read  only 
environment . 

b.  Directorates.  The  following  directorates  will  establish 
internal  procedures  to  insure  that  data  used  by  their  functions  are 
maintained  accurately  and  completely.  Attachments  1  and  2  will  be 
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the  guide  to  establishing  the  OPRs  for  all  data  in  the  AFIT 
database.  SC  will  review  all  accesses  to  insure  conflicts  do  not 

arise. 

(1)  Evaluation  and  Admissions  Division  (RRE)  is 

responsible  for  initially  inputting  data  on  all  students  selected 
for  an  AFIT  educational  program. 

(2)  Scheduling  And  Registration  (RRDS)  will  be 
responsible  for  updating  any  inforaation  related  to  student 
enrollment  and  AFIT's  academic  environment  using  AFIT  Student 
Information  System  (AFITSIS)  applications. 

(3)  The  Sguadron  Section  Comnfander  (CCQ)  will  be 
responsible  for  maintaining  information  concerning  faculty  and 
staff  members,  personal  information  on  students  enrolled  in  an  AFI 
resident  program  (AFITSIS)  ,  and  other  information  related  to  Air 

Force  programs. 

(4)  The  resident  schools  (ENA,  LSA,  and  DEV)  will  be 
responsible  for  school  related  validation  and  student  career 
information  (AFITSIS)  . 

(5)  Departments  of  each  resident  school  will  be 

responsible  for  establishing  course  of  graduation 

standards,  and  student  education  planning  (AFITSIS). 

(6)  Civilian  Institutions  (Cl)  personnel  are  responsible 
for  all  information  concerning  students  enrolled  in  Civilian 
Institution  Regular,  Health,  and  Special  progr^s  using  Management 
information  Financial  Forcasting  System  (MIFFS)  applications. 

(7)  Directorate  of  Resource  Management  Finance  Branch 
(ACF)  is  responsible  for  information  concerning  management  of  f^ds 
for  tuition,  fees,  etc.  for  students  enrolled  in  Civilian 
Institutions  Programs  (MIFFS) .  These  functions  are  yet  to  be 
implemented  in  MIFFS . 

4.  Revisions /updates:  Revisions  and  updates  to  this  regulation 
will  be  made  as  new  capabilities  are  developed  or  whenever 
functional  responsibilities  change,  on  an  as  required  basis. 


OFFICIAL 


FREDERICK  C.  BAUER,  Colonel,  USAF 
Commandant 
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1.  AFITSIS  Field  OPRs 

2.  MIFFS  Field  OPRs 
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AFITSIS  Field  OFRs 


User  Classes 


Registrar 

(RRDS) 

School  Administration 

(ADMIN) 

(ADMINLD) 

(ADMINEN) 

(ADMINLS) 

(ADMINC) 

(ADMINS) 

(ADMINP) 

(ADMINE) 

Orderly  Room 

(CCQ) 

Quota  Book 

(RRE) 

International  Students 

(RRI) 

School  Departments 

(DEPT) 

(DEPTC) 

(DEPTS) 

(DEPTP) 

(DEPTE) 

AFIT  Personnel  System 

(DEPTEN) 

(APS) 

SRSRRDS 

SRSENA,  SRSLSG,  SRSDEV 
SRSLSG,  SRSDEV 
SRSENA 
SRSLSG 

School  owning  the  course 

School  owning  the  student 

School  owning  the  program 

School  owning  the  specialty 

edplan 

SRSCCQ 

SRSRRE 

SRSRRI 

SRSENC,  SRSENG,  SRSENP, 
SRSENS ,  SRSENR ,  SRSENY , 
SRSLSA,  SRSLSG, 

SRSLSG,  SRSLSL,  SRSLSM, 
SRSLSQ,  SRSLSR,  SRSLSY 
Department  owning  the 

course 

Department  owning  the 

student 

Department  owning  the 

program 

Dept  owning  the  specialty 
edplan 

Any  EN  Department 
AFITAC,  AFITCC,  AFITCCQ, 
AFITCI,  AFITDP,  AFITEN, 
AFITENA,  AFITENC,  AFITENG, 
AFITENP,  AFITENS,  AFITENY, 
AFITIM,  AFITLD,  AFITLS, 
AFITLSA,  AFITLSG,  AFITLSL, 
AFITLSM,  AFITLSP, AFITLSQ, 
AFITLSR,  AFITLS Y,  AFITPA, 
AFITRM,  AFITRR,  AFITRRR, 
AFITSC,  AFITXP,  SC 
ACES,  ACF,  Cl,  CIA,  CIB, 
CIM,  CIME,  CIMJ,  CIR, 

CIRD,CIRG,  CIRK,  CISC, 
CISH,  CISP,  CISS,  MIFFS 


MIFFS 


(MIFFS) 
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Function  :  Insert  a  new  person  into  AFIT  Database 


1) 

Insert  a 
Form 
OPR 

full-time  student 
:  Selected  Student  Data 
:  RRE 

(SELECTION) 

2) 

Insert  a 
Form 
OPR 

part-time  student 
:  Personal  Information 
:  RRDS 

(ADMISSION) 

3) 

Insert  an  international  student 

Form  :  Applications  and  Evaluations  (INTL_EVALUATI0N) 

OPR  :  RRI 

4) 

Insert  an  international  sponsor 
Form  t  Sponsor  Information 

OPR  :  RRI 

( INTL_SPONSOR_DATA) 

5) 

Insert  s 
Form 
OPR 

taff /faculty 

Find/Update  Personnel  Information  (PMS_INFO) 

;  APS 

Function 

:  Update  personal  information 

1) 

Form 

OPR 

:  Selected  Student  Data 
;  RRE 

(SELECTION) 

2) 

Form 

OPR 

;  Personal  Information 
:  RRDS 

(ADMISSION) 

3) 

Form 

OPR 

:  Applications  and  Evaluations  (INTL_EVALUATION) 

:  RRI 

4) 

Form 

OPR 

:  Sponsor  Information 
:  RRI 

( INTL_SPONSOR_DATA) 

5) 

Form 

:  International 

Student  Information 

( INTL_STUDENT_DATA) 

OPR 

;  RRI 

6) 

Form 

OPR 

:  Family  Information 
;  RRI 

( FAMILy_INFORMATION) 

7) 

Form 

OPR 

:  Find/Update  Personnel 
:  APS 

Information  (PMS_INFO) 

8) 

Form 

OPR 

:  CCQ  Data  Entry  Screen 
:  CCQ 

(CCQ_DATA_ENTRY) 

9) 

Form 

OPR 

;  Student  Demographics 
:  ADMINS 

( STUDENT_DEMOGRAPHICS ) 
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10)  Form  :  Dependent  Information  (DEPENDENT_INFORMATION) 

OPR  :  ADMINS 

Function  ;  Change  a  person’s  name 

1)  Form  :  Change  a  Person's  Name  (NAME_HIST) 

OPR  ;  RRDS,  RRE 

Function  :  Change  a  SSAM 

1)  Form  :  Change  a  Person's  SSAN  (SSAN_UPDATE) 

OPR  :  RRDS,  RRE 

Function  ;  Delete  a  person  from  AFIT  Database 

1)  Form  ;  None 

OPR  :  None 
Fields  :  None 


Function  :  Insert  into  validation  tables 


1) 

Form 

:  All  validation  forms 

Note 

:  Refer  to  the  validation 

tables  addendum 

Function 

:  Address  information 

1) 

Form 

:  Address  Information 

(ADDRESS_DATA) 

OPR 

;  ADMINS,  CCQ,  RRDS,  RRI 

2) 

Form 

:  Find/Update  Address  and 

Locator  Information 

OPR 

:  APS 

(EMS_AI») 

Function 

:  AFITNET  Username 

1) 

Form 

:  CCQ  Data  Entry 

( CCQ_DATA_ENTRY ) 

OPR 

:  CCQ 

2) 

Form 

:  Resident  Student  Information 

(VIEW  RESIDENT_SCHOOL  INPUT) 

OPR 

:  ADMINS 

Function 

:  AFIT 

course  catalog 

1) 

Form 

:  Course  Catalog 

(COURSE_CATALOG) 

OPR 

:  RRDS 

2) 

Form 

:  Course  Prerequisites 

(  PREREQ_MAINTENANCE ) 

OPR 

:  RRDS 

3) 

Form 

:  Course  Corequisites 

(  COREQ_MAINTENANCE ) 

OPR 

:  RRDS 

6  AFITR  700-xx,  Attachment  1/  4  Sep  91 

Function  ;  Sxibmit  Form  51  to  change  the  AFIT  course  catalog 


Form  :  New  Course  Entry 

OPR  :  DEPTC 


(NEW_COURSES) 


Function  :  Create  and  update  the  course  schedule 


Form  :  Rollover  Courses  from  Offerings 

(R0L]j0VER_FROM_OFFERINGS  ) 

OPR  :  RRDS 

Form  :  Rollover  Single  Course  from  Catalog 

JROLLOVER_SINGLE_COURSE) 

OPR  :  RRDS 

Form  :  Create  Course  Sections  (CREATE_COURSE_SECTIONS) 
OPR  :  RRDS 

Form  :  Schedule  Course  Times  (SCHEDULE_COURSE_TIMES) 


Form 

OPR 

Form 


Form 


Form 

OPR 


RRDS 

Modify  Schedule  Notes 
RRDS 


( SCHEDULE_NOTES ) 


Modify  Schedule  Room  Requirements 

( SCHEDULE_ROOM_REQUIREMENTS ) 

RRDS 

School  Schedule  Course  Tines 

( SCHOOL_SCHEDUIiE_TIMES ) 

ADMINC 

Delete  Vacant  Courses  (DELETE_UNREG_COURSES) 
RRDS 


Function  :  Submit  course  offerings 


Form 

OPR 

Form 

OPR 

Form 


Form 


:  course  Offerings  (COURSE_OFFERINGS) 

:  DEPTC,  ADMINC,  RRDS 

Rollover  Course  Offerings  (ROLLOVER_OFFERINGS) 
:  DEPTC,  ADMINC,  RRDS 

;  Course  Offerings  Remarks 

(COURSE_OFFERINGS_REMARKS ) 

:  DEPTC,  ADMINC,  RRDS 

:  Change  Course  Offering  Status 

( COURSE_CANCELLATION) 

:  DEPTC,  ADMINC,  RRDS 


OPR 
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5)  Form  :  Request  Department  to  Offer  Course 

(DEPARTMENT_REQUEST_COURSE) 

OPR  :  DEPTC,  ADMIN 


Function  ;  Graduation 


1) 

Form 

OPR 

:  Graduation  Candidates  by  Term  (GRADUATION) 

:  RRDS 

2) 

Form 

OPR 

:  Award  Double  Degrees 
:  RRDS 

(DOUBLE_DEGREE) 

3) 

Form 

OPR 

:  CST  Certification 
:  RRDS 

(CST  CERTIFICATION) 

4) 

Form 

OPR 

:  PSE  Certification 
:  RRDS 

(PSE_CERTIFICATION) 

5) 

Form 

OPR 

:  Reactivate  Graduated  Student  (UNGRADUATE) 

:  RRDS 

Function 

:  Dependents  information 

1) 

Form 

OPR 

:  CCQ  Data  Entry 
:  CCQ 

( CCQ_DATA_ENTRY ) 

2) 

Form 

OPR 

:  Dependent  Information 
:  ADMINS 

(DEPENDENT_INFORMATION) 

3) 

Form 

OPR 

:  Student  Demographics 
:  ADMINS 

( STUDENT_DEMOGRAPHI  CS ) 

Function 

:  Duty 

history 

1) 

Form 

OPR 

:  Duty  History  Information  (DUTY  HISTORY) 

;  ADMINS 

2) 

Form 

OPR 

:  Student  Demographics 
:  ADMINS 

(  STUDENT_DEMOGRAPHICS ) 

3) 

Form 

OPR 

:  CCQ  Data  Entry 
:  CCQ 

(  CCQ_DATA_ENTRY ) 

4) 

Form 

OPR 

:  Gaining  and  Losing  Duty  Information 

(BASE  MAJCOM  INFORMATION) 

:  ADMINS 

5) 

Form 

OPR 

:  Gaining  and  Losing  Duty  Information  for 
Graduated  Students 

(GRAD  BASE  MAJCOM  INFORMATION) 

:  ADMINS 
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Function  :  Student  edplan  related  information 


1) 

Form 

OPR 

2) 

Form 

OPR 

3) 

Form 

OPR 

4) 

Form 

OPR 

5) 

Form 

OPR 

6) 

Form 

OPR 

7) 

Form 

OPR 

8) 

Form 

OPR 

9) 

Form 

OPR 

10) 

Form 

OPR 

11) 

Form 

OPR 

12) 

Form 

OPR 

13) 

Form 

OPR 

14) 

Form 

OPR 

:  Enter  a  Student's  Edplan  Comments  (EDPLAN_DESC) 
:  ADMINS,  DEPTS 


:  Thesis  Information 
RRDS,  ADMINS,  DEPTS 


(THESIS_INFORMATION) 


Create  Specialty  Edplans 

( CREATE_SPECIALTY_EDPLAN) 

ADMINLD,  DEPTE 

Assign  Specialty  Edplan  to  Students 

( REGI  §TRATION_B  Y_SPEC_EDPLAN ) 

DEPTS 


Create  program  Edplan 
DEPTP 

Rollover  Program  Edplan 
ADMIN,  DEPT 


(PROGRAM_PIAN) 

(ROLLOVER_EDPIAN) 


Rollover  Program  Edplan  by  Quarter 

( ROLLOVER_EDPLAN_BY_QUARTER) 

DEPT 

Assign  Program  Edplan  to  Students 

(ASSIGN_EDPIANS) 

DEPTP 

Register  a  Student  for  Courses 

( SCHOOL_REGISTRATION) 

DEPTS 

Record  of  Non-AFIT  Courses  (TRANSFER_CREDITS) 
RRDS 

Drop  or  Add  to  Student  Schedule 

(RRDS_SCHEDULrNG) 

RRDS 

Change  Students  Credit  Hours  for  a  Course _ 

( CHANGE_CREDIT_ROSTER) 

RRDS 


Register  Students 
RRDS 

Student  Maintenance 
RRDS 


(REGISTRATION_ROSTER) 

(CHANGEJSRADE) 
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15) 

Function 

1) 

2) 

3) 

4) 

5) 


Forin 

OPR 


:  Enter  a  Student's  Major(s) 
:  DEPTS,  ADMINS 


and  Option (s) 

(MAJORSJDPTICWS) 


Education  history 

Form  :  Educational  Background  (ED_HIsr) 

OPR  :  RRDS 


Form  :  Student's  educational  Background 

(  SC3iOOL_EDUCATION_HI  STORY ) 

OPR  :  ADMINS,  DEPTS 

Form  :  Applications  and  Evaluations  (INTL_EVALUATION) 
OPR  ;  RRI 


Form  :  Graduation  Candidates  by  Term  (GRADUATION) 

OPR  :  RRDS 


Form  :  Reactivate  Graduated  Student  (UNGRADUATE) 

OPR  :  RRDS 


Function  :  Exzua  scheduling 

1)  Form  :  Schedule  Exam  Times  (SCHEDULE_EXAM_TIMES) 

OPR  ;  RRDS 

Function  :  Fitness  test  results 

1)  Form  :  Weigh-in/ Aerobics  (WEIGH_IN_AEROBICS) 

OPR  :  CCQ 

Function  :  Entering  graduating  students'  grades 

1)  Form  :  Graduating  Students'  Grades 

(GRAD_GRADES_ROSTER) 

OPR  :  ADMINLS,  DEPTS,  RRDS 

Function  :  Entering  non-graduating  students'  grades 

1)  Form  ;  student  Grades  by  Course  (GRADE_ROSTER) 

OPR  :  RRDS 

2)  Form  :  Student  Maintenance  (C3iANGE_GE»DE) 

OPR  :  RRDS 

Form  :  Course  Grade  Maintenance  (CHANGE_GRADE_ROSTER) 
OPR  :  RRDS 


3) 
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Function  :  Drop  and  add 


Function 


Form  :  Drop  or  Add  to  Student  Schedule 


(RRDS_SCHBDULING) 


:  RRDS 


Student's  AFIT  transcript  and  degree  related  information 

(excluding  registration,  graduation  and  grades) 

Form  :  Enter  a  Student's  Major (s)  and  Options (s) 

(MAJ0RS_0PTI0NS) 

OPR  :  DEPTS,  ADMINS 


Form 

OPR 

Form 

OPR 

Form 


Form 

OPR 

Form 

OPR 


Admission 

RRDS 

Educational  Background 

RRDS 


(AEMISSICW) 


(ED  HIST) 


;  Student's  Educational  Background 

(SC310OL_EDUCATI0N_HISTORy) 

:  ADMINS,  DEPTS 

Applications  and  Evaluations  (INTL_EVALUATION) 
:  RRI 


Thesis  Information 
RRDS,  DEPTS,  ADMINS 


(THESIS_DISSERrATION) 


Function  :  Student's  AFIT  related  information 


1) 

Form 

;  Resident  Student 

Information 

(VIEW  RESIDENT_SCHOOL_INPUT) 

OPR 

:  ADMINS,  DEPTS 

2) 

Form 

:  Admission 

(AnCSSION) 

OPR 

:  RRDS 

3) 

Form 

;  Assign  Program  Sections  and  Leader  positions 

(PROGRAM  SECTION_ASSIGNMENTS) 

OPR 

;  ADMINS 

4) 

Form 

:  Change  a  Student 

s  Registration  Department 

(CHANGE  STUDENT_REGS_DEPT) 

OPR 

:  DEPTS 

5) 

Form 

:  Box  Number  Assignments  (B0X_NUMBER_ASSIGNMENTS) 

OPR 

:  CCQ 

6) 

Form 

:  CCQ  Data  Entry 

( CCQ_DATA_ENTRY ) 

OPR 

:  CCQ 
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7) 

Form 

:  Student  Demographics  (STUDENT_DEMOGRAPHICS) 

OPR 

:  ADMINS 

8) 

Form 

:  Section  Leader  Assignments 

( SECTION_LEADER_ASSIGNMENTS ) 

OPR 

:  CCQ 

9) 

Form 

:  Program  Advisor  Assignments 

(ASSIGN_PROGRAM_ADVISOR) 

OPR 

:  CCQ,  DEPTP 

10) 

Form 

:  Locker  Nximber  Assignments  (LOCKER_ASSIGNMENTS) 

OPR 

;  CCQ 

11) 

Form 

:  Building  Access  Card  Assignments 

(BUILDING_ACCESS_CARDS ) 

OPR 

:  CCQ 

12) 

Form 

:  Change  a  Person's  Rank  (RANK_HIST) 

OPR 

;  CCQ,  RRDS,  RRE 

13) 

Form 

:  Weigh  In/ Aerobics  (WEIGH_IN_AEROBICS) 

OPR 

:  CCQ 

14) 

Form 

:  Weight  Management  Program 

(WEIGHT_MANAGEMENT_PROGRAM) 

OPR 

:  CCQ 

15) 

Form 

:  Assign  Duty  (ASSIGN_DUTY) 

OPR 

:  CCQ 

16) 

Form 

:  Security  Access  Badge  Assignments 

(BADGEJTOMBERS) 

OPR 

:  CCQ 

17) 

Form 

;  Delete  Badges  for  Graduating  Students 

(DELBrE_BADGES) 

OPR 

:  CCQ 

Ftinction  :  Additional  duties 

1)  Form  :  Assign  Duty  (ASSIGN_DUTY) 

OPR  ;  CCQ 

Function  :  Academic  advisor  assignments 

1)  Form  :  Assign  Academic  Advisors  by  Program/ASC 

(  ASSICa^_ACADEMIC_ADVI  SOR) 

OPR  :  ADMINS,  DEPTS 
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2 )  Form 


3) 


OPR 

Form 

OPR 


Assian  Student  an  Academic  Advisor 

^  (FACULTY_ADVISOR) 

ADMINS,  DEPTS 


Resident  Student  Information 

(VIEW_RESIDENT_SCHOOL_INPUT) 

ADMINS,  DEPTS 


Function  :  Security  Badges 


1)  Form 
OPR 


Security  Access 
CCQ 


Badge  Assignments 

(BADGE_NUMBERS) 


2 )  Form 
OPR 

Function  :  IMT  information 


1) 

Form 

OPR 

:  Applications  and  Evaluations  (INTL_EVALUATION) 

:  RRI 

2) 

Form 

:  International  Student 

Information 

( INTL_STUDENT_DATA) 

OPR 

:  RRI 

3) 

Form 

OPR 

:  Assign  Student  an  Academic  Advisor 

( FACULTy_ADVISOR) 

:  ADMINS,  DEPTS,  RRI 

4) 

Form 

OPR 

:  Sponsor  Information 
:  RRI 

( INTL_SPONSOR_DATA) 

5) 

Form 

OPR 

:  Family  Information 
:  RRI 

( FAMILy_INFORMATION) 

6) 

Form 

OPR 

:  Address  Information  (ADDRESS_DATA) 

:  ADMINS,  CCQ,  RRDS,  RRI 

7) 

Form 

OPR 

;  Informational  Program  resources  (RESOURCES) 

:  RRI 

8) 

Form 

:  Informational  Program 

Attendance 

(IP_ArrENDANCE) 

OPR 

:  RRI 

9) 

Form 

:  Informational  Program 

Assessment 

( IP_ASSESSMENTS) 

OPR 

:  RRI 

•  Delete  Badges  for  Graduating  Students 

^  (DELEIE_BADGES) 

:  CCQ 
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Function 

:  Prograun 

edplans 

1) 

Form  : 

Create  Program  Edplan  (PROGRAM  PLAN) 

OPR  : 

DEPTP 

2) 

Form  : 

Rollover  Program  Edplan  (ROLLOVER  EDPLAN) 

OPR  : 

ADMIN,  DEPT 

3) 

Form  : 

Rollover  Program  Edplan  by  Quarter 

(ROLLOVER  EDPLAN  BY  QUARTER) 

OPR  : 

ADMIN,  DEPT 

Function 

:  Registration  by  program  edplan 

1) 

Form  : 

Assign  Program  Edplan  to  Students 

(ASSIGN  EDPLANS) 

OPR  : 

DEPTP 

Function 

;  Program 

Sections 

1) 

Form  : 

Assign  Program  Edplan  to  Students 

(PROGRAM  SECTION  ASSIGNMENTS) 

OPR  : 

ADMINS 

2) 

Form  : 

Section  Leader  Assignments 

(SECTION  LEADER  ASSIGNMENTS) 

OPR  : 

CCQ 

Function 

:  Program 

sequence  edplans 

1) 

Form  : 

Create  Specialty  Edplans 

(CREATE  SPECIALTY  EDPLAN) 

OPR  : 

DEPTE,  ADMINLD 

Function 

1) 


:  Registration  by  progrznn  sequence  edplan 

Form  :  Assign  Specialty  Edplan  to  Students 

(ASSIGN_BY_SPEC_EDPLAN) 


OPR  :  DEPTE 


Function  :  Section  Leaders 


1) 

Form 

:  Assign 

Program  Sections  and  Leader  Positions 

(  PROGRAM_SECTION_ASSIGNMENTS ) 

OPR 

:  ADMINS 

2) 

Form 

:  Section 

,  Leader  Assignments 

( SECTION_LEADER_ASSIGNMENTS ) 

OPR 

:  CCQ 
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Function  :  Spouse  information 


1) 

Form 

OPR 

• 

Sponsor  Information 

RRI 

(INTL  SPONSOR_DATA) 

2) 

Form 

OPR 

• 

• 

• 

Find/Update  Personnel  Information  (PMS_INFO) 

APS 

3) 

Form 

OPR 

• 

• 

• 

• 

Family  Information 

RRI 

( FAMILY_INF0RMATI0N) 

4) 

Form 

• 

• 

CCQ  Data  Entry 

( CCQ_DATA_ENTRY ) 

OPR 

• 

• 

CCQ 

5) 

Form 

OPR 

• 

• 

• 

• 

Student  Demographics 
ADMINS 

( STUDENT_DEMOGRAPHICS ) 

6) 

Form 

OPR 

• 

Dependent  Information 
ADMINS 

( dependent_information ) 

Function 

1) 

2) 

3) 

Function 

1) 


National  entrance  test  scores 


Form 

OPR 

Form 

OPR 

Form 

OPR 


(TEST_SCORES) 

(STATS) 


Test  Scores 
RRDS 

Statistical  Data 
RRE 

Applications  and  Evaluations  (INTL_EVALUATION) 
RRI 


Transfer  and  SOCHE  course 

Form  :  Record  of  Non-AFIT  Course  (s)  (TRANSFER_CREDITS) 

OPR  :  RRDS 


yunction  s  Department  Head 

1) 


Form 

OPR 


Update  Department  Data 
ADMINS 


Function  :  Height  management  program 

1) 


2) 


Form 

OPR 

Form 


Weigh  In/Aerobics 
CCQ 


( DEPARTMENT__UPDATE ) 


(WEIGH_IN_AEROBICS ) 


Weight  Management  Program 

^WEIGHT  MANAGEMENT  PROGRAM) 


OPR 


CCQ 


AFITR  700-xx,  Attachment  1#  4  Sep  91  15 


Function  :  Department  of  registration 


1) 

Form 

:  Student  Demographics  (STUDENT_DEMOGRAPHICS) 

OPR 

:  ADMINS 

2) 

Form 

:  Admission 

(ADMISSION) 

OPR 

:  RRDS 

3) 

Form 

:  Change  a  Student's 

Program  ( PROGRAM_HI ST ) 

OPR 

:  RRDS 

4) 

Form 

:  Change  a  Student's 

Registration  Department 
( CHANGE_STUDENT__REGS_DEPT) 

OPR 

:  DEPTS 

Function 

:  Emergency  contact 

1) 

Form 

:  Emergency  Contact 

Information 

(EMERGENCY_CONTACT) 

OPR 

;  RRDS ,  ADMINS 

2) 

Form 

:  CCQ  Data  Entry 

(CCQ_DATA_ENTRy) 

OPR 

:  CCQ 

3)  Form  ;  Student  Demographics  (STUDENT_DEMOGRAPHICS) 

OPR  :  ADMINS 

Function  :  Change  a  person’s  rank 

1)  Form  :  Admission  (ADMISSION) 

OPR  :  RRDS 

2)  Form  :  Change  a  Person's  Rank  (RANK_HIST) 

OPR  :  RRDS,  CCQ,  RRE 

Function  :  Change  a  student's  program 

1)  Form  :  Admission  (ADMISSION) 

OPR  :  RRDS 

2)  Form  :  Change  a  Student's  Program  (PROGRAM_HIST) 

OPR  ;  RRDS 


Fimction  :  Change  a  grade 

1)  Form  :  Record  of  Non-AFIT  Courses  (TRANSFER_CREDITS) 

OPR  :  RRDS 


2)  Form 
OPR 


Student  Maintenance 
RRDS 


(CHANGE_GRADE) 
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3) 

Form 

OPR 

• 

Student  Grades  by  Course 
RRDS 

(GRADE_ROSTER) 

4) 

Form 

OPR 

1 

Course  Grade  Maintenance 
RRDS 

( CHANG E_GRAD E_RO S TER ) 

5) 

Form 

: 

Graduating  Students'  Grades  . , 

y  (GRAD_GRADES_RDSTER) 

OPR 

: 

DEPTS 

Function 

:  Change  credit  hours  for  a  course 

1) 

Form 

« 

• 

Register  a  Student  for 

Courses 

'■*  (SCHOOL_REGISTRATION) 

OPR 

DEPTS 

2) 

Form 

OPR 

• 

* 

• 

Record  of  Non-AFIT  Courses  ( TRANS FER_CREDITS) 
RRDS 

3) 

Form 

• 

• 

Drop  or  Add  to  Student 

Schedule 

(RRDS_SCHEDULING) 

OPR 

• 

• 

RRDS 

4) 

Form 

• 

• 

Change  Students'  Credit  Hours  for  a  Course 

^  (CHANGE_CREDIT_ROSTER) 

OPR 

m 

RRDS 

Function 

;  Single  course  registration 

1) 

Form 

• 

Drop  or  Add  to  Student 

Schedule 

(RRDS_SCHEDULING) 

OPR 

• 

RRDS 

Function 

•  Reactivate  a  graduated  student 

1) 

Form 

PR 

• 

• 

• 

Reactivate  Graduated  Student  (UNGRADUATE) 

RRDS 

Function 

:  PSE 

and 

CST  Certification 

1) 

Form 

OPR 

• 

PSE  Certification 

RRDS 

(PSE  CERTIFICATION) 

2) 

Form 

1 

CST  Certification 

(CST  CERTIFICATION) 

OPR  :  RRDS 

Function  :  Delete  a  resident  student 


1)  Form  :  Delete  Resident  Student  (DELETE_RESIDENT) 

OPR  :  RRDS 
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Function 

1) 


:  Insert  a  new  course  into  the  course  catalog 

Form  :  Insert  New  Course  into  Course  Catalog 

( INSERT_NEW_COURSE ) 


OPR  :  RRDS 


Function  :  Assign  instructors  to  courses 

1)  Form  :  Assign  Instructor's  Courses  (INSTRUCTORS_COURSES) 
OPR  :  RRDS 

Function  :  Change  a  student's  graduation  date 

1)  Form  :  Change  a  Student's  Graduatioh  Date  (GRAD_HIST) 

OPR  :  RRDS 

Function  :  Delete  a  selected  student 

1)  Form  :  Delete  Selected  Student  (DELETE_SELECTED) 

OPR  :  RRE 

Function  :  Archive  Quota  Book  information 

1)  Form  :  Archive  Quota  Book  Information  (ARCHIVE_QUOTA) 

OPR  :  RRE 
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TTger  Classes 


MIFFS  Field  OPRS 

MTFrc:  TTger  Categories 


Cl  System  Administrator  (SYS_ADMIN) 
Quota  Book  (RRE) 

miffs  (ACES) 

(ACF) 

(Cl) 

(CIA) 

(CIB) 

(CIM) 

(CIME) 

(CIMJ) 

(CIMI) 

(CIR) 

(CIRD) 

(CIRG) 

(CIRK) 

(CISC) 

(CISH) 

(CISP) 

(CISS) 

(MIFFS) 

(CI_MED) 

(CI_PM) 


RRE 

ACES 

ACF 

Cl 

CIA 

CIB 

CIM'^ 

CIME 

CIMJ 

CIMI 

CIR 

CIPD 

CIRG 

CIRK 

CISC 

CISH 

CISP 

CISS 

MIFFS 

CIM,  CIMI,  CIMJ 
CIM,  CIMI,  CIMJ,  CIR,  CIRD 
CIRG,-  CIRK,  CISC,  CISH 
CISS,  CISP 
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Function  : 


Function  : 


Function  : 


Function  : 


Function  : 


Function 


Function 


Function 


Function 


Function 


Function 


Function 


Insert  a  new  person  into  ACES 

Form  :  PERSON 

OPR  :  RRE,  CI_PM 

Update  an  existing  person  in  ACES 

Form  :  PERSON 

OPR  :  CI_PM  (PM  may  only  update  own  students) 

Insert  a  Book  Allowance  Entry  for  a  Student 

Form  :  BOOK_ALLOWANCE_QUARTERS 

OPR  :  SYS_ADMIN 

Update  a  Book  Allowance  Entry  for  a  Student 

Form  :  BOOK_ALLOWANCE_QUARTERS- 

OPR  :  SyS_ADMIN 

Print  the  Annual  Book  Allowance  Roster 
Form  :  PRINT_ANNUAL_BOOK_ROSTER 

OPR  :  SYS_ADMIN 

Print  the  Quarterly  Book  Allowance  Roster 
Form  ;  PRINT_QUARTERLY_BOOK_ROSTER 

OPR  :  SYS_ADMIN 

Print  the  Annual  Book  Roster  for  the  Finance  Office 
Form  :  PRINT_FIN_BOOK_ROSTER_ANNUAL 

OPR  :  ACF 

Print  the  Quarterly  Book  Roster  for  the  Finance  Office 
Form  :  PRINT_FIN_BOOK_ROSTER_QUARTER 

OPR  :  ACF 

:  Insert  Thesis/Dissertation  Information  for  a  Student 
Form  :  THESIS_DISSERTATION 

OPR  :  CIM,  CIMI,  CIR,  CIRD,  CIRK,  CISP,  CISS 

:  Update  Thesis/Dissertation  Information  for  a  Student 
Form  :  THESIS_DISSERTATION 

OPR  ;  CIM,  CIMI,  CIR,  CIRD,  CIRK,  CISP,  CISS 

:  Delete  Thesis/Dissertation  Information  for  a  Student 
Form  :  THESIS_DISSERTATION 

OPR  ;  CIM,  CIMI,  CIR,  CIRD,  CIRK,  CISP,  CISS 

:  Insert  HPSP  ADT  Information  for  a  Student 

Form  :  HPSP_STUDENT_ACTIVE_DUTY_TOUR 

OPR  :  CIMJ 

:  Update  HPSP  ADT  Information  for  a  student 

Form  :  HPSP_STUDENT_ACTIVE_DUTY_TOUR 

OPR  :  CIMJ 


Function 
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Function  :  Delete  HPSP  ADT  Information  for  a  Student 

Form  :  HPSP_STUDENT_ACTIVE_DUTy_TOim 

OPR  :  CIMJ 

Function  :  Insert  an  HPSP  ADT  Deferral  for  a  Student 
Form  :  HPSP_ADT_DEFERRAL 

OPR  :  CIMJ 

Function  :  Update  an  HPSP  ADT  Deferral  for  a  Student 
Form  :  HPSP_ADT_DEFERRAL 

OPR  :  CIMJ 


Function 


Insert  a  new  HPSP  ADT  Course 

Form  :  ENTER_HPSP_ADT_C0URSE_IKF0 

OPR  :  CIMJ 


Function  :  Update 
Form 
OPR 


an  HPSP  ADT  Course 

:  ENTER_HPSP_ADT_C0URSE_INF0 

:  CIMJ 


Function 


Insert  Medical  Education  Director  Information 
Form  :  MEDICAL_EDUCATION_DIRECTOR 

OPR  :  CIMJ 


Function 


Update  Medical  Education  Director  Information 

Form  :  MEDICAL_EDUCATION_DIRECTOR 

OPR  :  CIMJ 


Function 


Delete  Medical  Education  Director  Information 

Form  :  MEDICAL_EDUCATION_DIRECTOR 

OPR  :  CIMJ 


Function  :  Insert  an  Address  for  a  Student 

Form  t  ADDRESS_DATA 

OPR  :  CI_PM 

Fields  : 


Function  :  Update  an  Address  for  a  Student 
Form  i  ADDRESS_DATA 

OPR  :  CI_PM 

Function  t  Delete  an  Address  for  a  Student 
Form  :  ADDRESS_DATA 

OPR  :  CI_PM 

Function  :  Insert  Spouse  Information  for  a  Student 
Form  :  SPOUSE 

OPR  :  CI_PM,  CIA 

Function  :  Update  Spouse  Information  for  a  Student 
Form  :  SPOUSE 

OPR  :  Cl  PM,  CIA 
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Function  : 


*  Function  : 

Function  : 


Function  : 


Function  : 


Function  : 


Function 


Function 


Function 


Function 

Function 


Function 


Function 


Delete  Spouse  Information  for  a  student 

Form  :  SPOUSE 

OPR  :  CI_PM,  CIA 

Insert  Dependent  information  for  a  Student 

Form  :  DEPENDENT 

OPR  :  CI_PM,  CIA 

Update  Dependent  information  for  a  student 

Form  :  DEPENDENT 

OPR  :  CI_PM,  CIA 

Delete  Dependent  Information  for  a  Student 

Form  :  DEPENDENT 

OPR  :  CI_PM,  CIA 

Insert  Prior  Military  Service  Information  for  a  Student 
Form  :  PRIOR_MILITARy_SERVICE 

OPR  :  CI_PM  (except  CISC) 

Update  Prior  Military  Service  Information  for  a  Student 
Form  ;  PRIOR_MILITARY_SERVICE 

OPR  :  CI_PM  (except  CISC) 

Delete  Prior  Military  Service  Information  for  a  Student 
Form  :  PRIOR_MILITARY_SERVICE 

OPR  :  CI_PM  (except  CISC) 

Insert  Clearance  Information  for  a  Student 
Form  :  CLEARANCE 

OPR  :  CIA 

Update  Clearance  Information  for  a  Student 
Form  :  CLEARANCE 

OPR  :  CIA 

:  Delete  Clearance  Information  for  a  Student 
Form  :  CLEARANCE 

OPR  :  CIA 

:  Insert  Submittal  Information  for  a  Student 
Form  :  STUDENT_SUBMITTAL 

OPR  :  CI_PM,  CIA 

:  Update  Submittal  Information  for  a  Student 
Form  :  STUDENT_SUBMITTAL 

OPR  :  CI_PM,  CIA 

:  Delete  Submittal  Information  for  a  Student 

Form  :  STUDENT_SUBMITTAL 

OPR  :  Cl  PM,  CIA 
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Function  : 


Function  : 


Function  : 


Function  : 


Function  : 


Function 


Function 


Function 


Function 


Function 


Function 


change  a  Student's  Rank 

Form  t  RANK_HIST 

OPR  :  CI_PM 

Change  a  Student's  Name 

Form  '  NAME_HIST 

OPR  :  CI_PM 

Insert  National  Test  Scores  for  a  Student 

Form  :  TEST_SCORES 

OPR  :  CI_PM,  RRE 

Update  National  Test  Scores  for  a  student 

Form  :  TEST_SCORES 

OPR  :  CI_PM,  RRE 

Delete  National  Test  Scores  for  a  Student 

Form  :  TEST_SCORES 

OPR  :  CI_PM,  RRE 

Place  a  Student  in  the  Weight  Management  Program 
Form  :  WEIGHT_MGMT_PROGRAM 

OPR  :  CIA 

:  Update  information  on  Student  in  the  weight  Management 
Progrzun 

Form  :  WEIGHT_MGMT_PROGRAM 

OPR  :  CIA 

:  Delete  Information  on  Student  in  the  Weight  Management 
Progreun 

Form  :  WEIGHT_MGMT_PROGRAM 

OPR  :  CIA 

:  insert  a  student  into  the  Nomogram  Program 

Form  ‘  NOMOGRAM_PROGRAM 

OPR  :  CIA 

:  Update  a  student  in  the  Nomogram  Program 
Form  :  NOMOGRAM_PROGRAM 

OPR  :  CIA 

:  Delete  a  Student  from  the  Nomogram  program 

Form  J  nomogram_program 

OPR  :  CIA 

:  Insert  a  Student  as  a  Liaison  Officer 
Form  :  LIAISON_OFFICER 

OPR  :  CIA 


Function 
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Function  j  Delete  Liaison  Officer  Information 

Form  :  LIAISON_OFFICER 

OPR  :  ACES 


Institution  Related  Functions 

Function  :  Insert  a  civilian  Institution 
Form  :  CIVILIAN_INSTITUTION 
OPR  :  CIA 

Function  :  Update  a  Civilian  Institution 
Form  :  CIVILIAN_INSTITUTION 
OPR  :  CIA 

Function  :  Insert  a  Civilian  Institution  Point-of-Contact 
Form  :  CIV_INS_POINT_OF_CONTACT 

OPR  :  CI_PM,  ACF,  CIA,  Cl 

Function  :  Update  a  Civilian  Institution  Point-of-Contact 
Form  :  CIV_INS_POINT_OF_CONTACT 

OPR  :  CI_PM,  ACF,  CIA,  Cl 

Function  :  Delete  a  Civilian  Institution  Point-of-Contact 
Form  ;  CIV_INS_POINT_OF_CONTACT 

OPR  :  CI_PM,  ACF,  CIA,  Cl 

Function  :  Insert  Residency  Information  for  a  Civilian  Institution 

Form  :  CIV_INS_RESIDENCy_GRANTED 

OPR  :  CI_PM 

Function  :  Update  Residency  Information  for  a  Civilian  Institution 

Form  :  CIV_INS_RESIDENCY_GRANTED 

OPR  :  CI_PM 

Function  :  Delete  Residency  Information  for  a  Civilian  Institution 
Form  :  CIV_INS_RESIDENCY_GRANTED 

OPR  :  CI_PM 

Function  :  Insert  University  Visit/Drug  Test  Information  for  a 
civilian  Institution 
Form  ;  UNIV_VISITS_DRUG_TESTS 

OPR  :  Cl,  CIA 

Function  ;  Update  University  Visit/Drug  Test  Information  for  a 
Civilian  Institution 

Form  :  UNIV_VISITS_DRUG_TESTS 

OPR  :  Cl,  CIA 
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Function  : 


Function  : 


Function  ; 


Function 


Function 


Function 


Function 


Function 
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insert  EHl  Company  CoorOinator  Information  tor  an  EWI 
site  (Civilian  Institution) 

Form  :  EWI_COMPANY_COORDINATOR 
OPR  CISK 

opiate  EWI  company  Coorainator  information  for  an  EWI 
Site  (Civilian  Institution) 

Form  :  EWI_COMPANY_COORDINATOR 

OPR  :  CISH 

insert  Medical  Program  Director  information  for  a 

Hospital  (Civilian  Institution) 

Form  :  MEDICAL_PROGRAM_DIRECTOR 

OPR  :  CIM 

opiate  Meiieal  Erogram  Director  information  for  a 

Hospital  (Civilian  Institution) 

Form  :  MEDICAL_PROGRAM_DIRECTOR 

OPR  :  CIM 

:  Delete  Meiieal  Program  Director  Information  for  a 

Hospital  (Civilian  Institution) 

Tori  :  medical_program_director 

OPR  :  CIM 


:  Insert  CBPO  information 
Form  ;  CBPO 

OPR  :  CIA 


:  Update  CBPO  Information 
Form  ••  CBPO 

OPR  :  CIA 


;  Delete  CBPO  Information 
Form  :  CBPO 

OPR  :  CIA 

;  Insert  ROTC  Detachment  Information 
Form  :  ROTC__DETACHMENT 

OPR  ;  CIA 

•  Update  ROTC  Detachment  information 
Form  :  ROTC^DETACHMENT 

OPR  :  CIA 


Function 
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Function  : 

*  Function  : 

k 

Function  : 

Function 

Function 

Function 

Function 

Function 


1 


Delete  ROTC  Detachment  Information 

Form  :  ROTC_DETACHMENT 

OPR  :  CIA 

Insert  Medical  Support  Unit  Information 
Form  :  MEDICAL_SUPPORT_UNIT 

OPR  :  CIA 

Update  Medical  Support  Unit  Information 
Form  :  MEDICAL_SUPPORT_UNIT 
OPR  :  CIA 

I  Delete  Medical  Support  Unit  Information 
Form  :  MEDICAL_SUPPORT_UNIT  ’■* 

OPR  :  CIA 

:  Change  a  Student's  SSAN 
Form  :  SSAN_UPDATE 
OPR  :  CIA 

;  Insert  a  Default  Printer  for  an  AFIT  Office 
Form  ;  DEFAULT_PRINTER 

OPR  :  All  ACES  Users 

:  Update  a  Default  Printer  for  an  AFIT  Office 
Form  :  DEFAULT_PRINTER 
OPR  :  All  ACES  Users 

:  Delete  a  Default  Printer  for  an  AFIT  Office 
Form  :  DEFAULT_PRINTER 
OPR  :  All  ACES  Users 
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